EP3991392A1 - Procede de gestion d'une communication entre terminaux dans un reseau de communication, et dispositifs et systeme pour la mise en oeuvre du procede - Google Patents

Procede de gestion d'une communication entre terminaux dans un reseau de communication, et dispositifs et systeme pour la mise en oeuvre du procede

Info

Publication number
EP3991392A1
EP3991392A1 EP20747451.1A EP20747451A EP3991392A1 EP 3991392 A1 EP3991392 A1 EP 3991392A1 EP 20747451 A EP20747451 A EP 20747451A EP 3991392 A1 EP3991392 A1 EP 3991392A1
Authority
EP
European Patent Office
Prior art keywords
terminal
connection
data
function
message
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
EP20747451.1A
Other languages
German (de)
English (en)
Inventor
Mohamed Boucadair
Christian Jacquenet
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Orange SA
Original Assignee
Orange SA
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Orange SA filed Critical Orange SA
Publication of EP3991392A1 publication Critical patent/EP3991392A1/fr
Pending legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/06—Network architectures or network communication protocols for network security for supporting key management in a packet data network
    • H04L63/061—Network architectures or network communication protocols for network security for supporting key management in a packet data network for key exchange, e.g. in peer-to-peer networks
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0823—Network architectures or network communication protocols for network security for authentication of entities using certificates
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/14—Network architectures or network communication protocols for network security for detecting or protecting against malicious traffic
    • H04L63/1408—Network architectures or network communication protocols for network security for detecting or protecting against malicious traffic by monitoring network traffic
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/16—Implementing security features at a particular protocol layer
    • H04L63/166—Implementing security features at a particular protocol layer at the transport layer
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/56—Provisioning of proxy services
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
    • H04L69/165—Combined use of TCP and UDP protocols; selection criteria therefor
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/18—Multiprotocol handlers, e.g. single devices capable of handling multiple protocols
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/10—Integrity
    • H04W12/102—Route integrity, e.g. using trusted paths
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00—Network arrangements, protocols or services for addressing or naming
    • H04L61/09—Mapping addresses
    • H04L61/25—Mapping addresses of the same type
    • H04L61/2503—Translation of Internet protocol [IP] addresses
    • H04L61/2514—Translation of Internet protocol [IP] addresses between local and global IP addresses
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/14—Network architectures or network communication protocols for network security for detecting or protecting against malicious traffic

Definitions

  • 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.
  • 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.
  • QUIC 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.
  • TLS Transport Layer Security
  • 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.
  • QoE Quality of Experience
  • cooperation must not induce additional connection establishment delays compared to those of connections which do not involve a network function.
  • the presence of such functions in the network can have an impact on the progress of a QUIC connection.
  • 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.
  • 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.
  • 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.
  • 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.
  • OF Offered Function
  • 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).
  • FEC detection and correction of errors
  • the result is a simplification of the use of QUIC clients on the terminals, thanks to a pragmatic collaboration with the network.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • DPI Deep Packet Inspection in English
  • an anti-virus function can be selectively invoked for certain packets, without being invoked. for all the packets exchanged during a QUIC communication.
  • 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.
  • the same channel may involve different functions during a connection, each being invoked exclusively for part of the data associated with this same channel.
  • the proposed method may further comprise: sending data via the first connection to the second terminal, data which does not correspond to said filter.
  • 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).
  • 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.
  • OF intermediate function
  • This embodiment makes it possible to reinforce the security of the proposed mechanism.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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 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
  • 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.
  • 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.
  • 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.
  • 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 illustrates a reference architecture for implementing the method proposed according to one or more embodiments.
  • 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 illustrates the correlation of a collaborative connection with the underlying network according to one or more embodiments.
  • FIG. 3a illustrates an example of a collaborative connection table (CCT) according to one or more embodiments.
  • FIG. 3b is a diagram illustrating the method proposed according to one or more embodiments.
  • FIG. 4a illustrates an example of QUIC COCON frame format according to one or more embodiments.
  • FIG. 4b illustrates an example table (TRS) for managing intermediate processing function usage information messages according to one or more embodiments.
  • 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 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 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 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 illustrates an example of a COCON (UPDATE) message format according to one or more embodiments.
  • FIG. 5 a is a diagram illustrating the method proposed according to one or more embodiments.
  • FIG. 5b illustrates an example of a collaborative connection relay table (RCCB) according to one or more embodiments.
  • RCCB collaborative connection relay table
  • FIG. 6a is a diagram illustrating the method proposed at the level of the remote terminal according to one or more embodiments.
  • FIG. 6b illustrates an example of a validated relayed stream (TRS) table according to one or more embodiments.
  • 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 illustrates an example of a method of processing a new packet at the remote terminal according to one or more embodiments.
  • FIG. 7a illustrates an example of rejection of an intermediate processing function according to one or more embodiments.
  • FIG. 7b illustrates an example of rejection of an intermediate processing function according to one or more embodiments.
  • FIG. 7c illustrates an example of rejection of an intermediate processing function according to one or more embodiments.
  • FIG. 7d illustrates an example of a successful collaborative connection according to one or more embodiments.
  • FIG. 7e illustrates an example of a successful collaborative connection according to one or more embodiments.
  • FIG. 7f illustrates an example of a successful collaborative connection according to one or more embodiments.
  • FIG. 8a illustrates an example of the architecture of a terminal according to one or more embodiments.
  • FIG. 8b illustrates an example of the architecture of a relay according to one or more embodiments.
  • 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.
  • 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.
  • 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.
  • computer storage medium s
  • computer storage medium 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.
  • 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.
  • 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.
  • 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.
  • application 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.
  • a user interface for example a graphical interface, in English, “Graphical User Interface” or GUI
  • GUI Graphic User Interface
  • 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 .
  • 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.
  • Packet 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.
  • function means any packet processing function.
  • NAT address translation
  • function a function intended to improve the quality of service
  • PEP Performance Enhancing Proxy
  • MPTCP proxy a service optimization function communications established on the TCP transport protocol (PEP, Performance Enhancing Proxy), MPTCP proxy, etc.
  • 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.
  • 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.
  • 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.
  • 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.
  • LAN local area networks
  • FIG. 1a is not limiting, in particular in that the terminals T1 and T2 can connect to the same access network.
  • 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.
  • a communication protocol such as the QUIC, UDP, DTLS, or TLS protocol
  • 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.
  • 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) ).
  • 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.
  • 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.
  • 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.
  • 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.
  • 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”).
  • Primary 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).
  • 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 ⁇ .
  • ⁇ a..x ⁇ is a list of primary channel IDs
  • ⁇ 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 ⁇ .
  • 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.
  • 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.
  • Figure 2c illustrates the correlation of a collaborative connection with the underlying network.
  • the different connections comprising the main connection (31c) and one or more secondary connections (32c, 33c)
  • 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.
  • the first terminal maintains a correspondence table, hereinafter called: Collaborative Connections Table (CCT).
  • CCT Collaborative Connections Table
  • 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.
  • FIG. 1 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
  • 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.
  • 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).
  • FIG. 3b is a diagram illustrating the method proposed according to one or more embodiments.
  • first and second terminals between which a first encrypted connection is established (50) to transmit data, for example according to the QUIC protocol.
  • 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.
  • 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.
  • the connection and channel identifiers are used as examples of filters, and the aforementioned information is stored in a CCT table as described previously.
  • 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.
  • 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.
  • 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).
  • this encryption is implemented according to a TLS security association established between the different devices two by two.
  • each section is individually encrypted.
  • 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.
  • 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.
  • the data can carry a new QUIC frame called
  • RELAY (List ⁇ Next_FIop_IP address / port ⁇ , Shared Token, 7), comprising, in one embodiment, the fields described below:
  • 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.
  • “Shared Token” Indicates a key to present for the next jump.
  • the same key can be used.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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).
  • 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.
  • 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.
  • COCON COllaborative CONnection
  • 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.
  • "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.
  • “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.
  • 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).
  • 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.
  • 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.
  • the list of connection identifiers indicated in a function use information message 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).
  • the direction of the invocation of the function can be deduced based on the direction of the associated channel.
  • 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).
  • 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. .
  • multiple OF function usage information messages may be sent if the first terminal decides to involve multiple OF intermediate processing functions.
  • 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.
  • an OF intermediate processing function can be embedded in a node located on the default (or not) data path.
  • 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).
  • 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).
  • 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.
  • the same table can be used regardless of the origin of the COCON frames.
  • 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").
  • 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.
  • 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.
  • 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).
  • Token A verification key which must be presented (by an OF function) to establish a new secondary connection associated with a primary connection.
  • 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).
  • 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.
  • 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).
  • a predetermined value eg called "Any" can be used to indicate that the function can be invoked for any identifier of a connection.
  • “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.
  • 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).
  • 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.
  • OF intermediate function
  • the confirmation message is a message called
  • 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
  • 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).
  • OF1 intermediate processing function
  • 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.
  • 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.
  • 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.
  • TRS table an offer table for the use of OF functions for the main connection with the terminal T2 (60b).
  • 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).
  • 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
  • the third channel (62c) is a unidirectional channel from T2 to T1.
  • the data of the different channels (62a, 62b, 62c) is also routed via the same path.
  • 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).
  • the terminal T1 (60a) can insert a COCON frame (OFl, mytoken, (streaml id, stream2_id ⁇ , ...) in a message intended for the terminal T2 (60b)
  • the terminal T2 (60b) can insert a COCON frame (OF2, myowntoken, stream3_id, ...) in a message intended for the terminal T1 (60a).
  • 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".
  • 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 .
  • a bidirectional channel can involve separate functions by direction of traffic.
  • 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:
  • 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).
  • 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.
  • 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.
  • 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
  • the third channel ( 62c) is a unidirectional channel from T2 to T1.
  • the terminal T1 (60a) can insert a frame
  • COCON (D l, OF3, mytoken, stream2_id, ...) in a message to the terminal T2 (60b).
  • 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.
  • 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.
  • COCON message UPDATE
  • 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:
  • “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.
  • Connection identifiers 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.
  • 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.
  • COCON frame UPDATE
  • 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.
  • FIG. 5a is a diagram illustrating the method proposed according to one or more embodiments, from the point of view of an intermediate function.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • the OF function can include a new QUIC frame called GLUE (Shared_Token, [mylD], ).
  • 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.
  • the OF function can on this occasion instantiate an entry in the RCCB table.
  • 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.
  • 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.
  • 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:
  • “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.
  • TLS / DTLS security associations for this purpose, rather than the ⁇ source address, source port, destination address, destination port ⁇ quadruplet, for greater reliability.
  • 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.
  • this field may have the same structure and the same semantics as the “Upstream Connection Reference” field described above.
  • Token This field corresponds to "Shared Token” received in a RELAY frame for an "Upstream” connection. This field is optional.
  • Extemal IP Address Indicates the IP address used by the OFi function as the source address to relay the packets of the connection.
  • Extemal Port Number Indicates the port number used by the OFi function as the source port number to relay the packets of the connection.
  • 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.
  • 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.
  • an OF function requested in both directions of a QUIC connection can maintain entries in its RCCB table which correspond. to each direction.
  • any packet intended for an OFi function can be processed according to the instructions of the RCCB table maintained by the OFi function.
  • the OFi function can consult its RCCB table to retrieve the reference of a "Downstream" connection, if necessary.
  • the OFi service 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.
  • 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.
  • 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).
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • the second terminal 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.
  • the terminal can update a TRS table to keep in memory data included in the COCON message.
  • 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:
  • TRS table illustrated in FIG. 6b contains the following information extracted from the COCON message:
  • OF ID an identifier of an OF function.
  • 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.
  • 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).
  • Token A verification key which must be presented to the second terminal (by an OF function) to establish a new secondary connection.
  • List of “Stream IDs” A filter which lists the channels whose data can be relayed by the function identified in the OF ID field.
  • 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.
  • Connection IDs A filter that lists connection identifiers whose data is subject to processing by the function identified in the OF ID field.
  • a predetermined value eg called "Any" can be used to indicate that the function can be invoked for any identifier of a connection.
  • the second terminal can be configured to retain an OF function only for a given direction.
  • 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.
  • An acknowledgment message of the COCON frame can then be sent to the first terminal.
  • 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.
  • 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:
  • the channel and connection identifier can be extracted according to the methods described in the QUIC specification.
  • 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.
  • 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.
  • 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.
  • 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.
  • a secondary connection eg, OF-T2
  • the second terminal ignores (92) the received GLUE frame if no entry is found in its TRS table.
  • 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.
  • 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.
  • the terminal 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.
  • 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).
  • 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. .
  • 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.
  • 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.
  • 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.
  • 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.
  • FIG. 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:
  • the second terminal T2 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.
  • DATA OF1 function data
  • RELAY frame @ T2, 485rFIjaKLkalBbjrCJghiD, .
  • 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, ).
  • a GLUE frame (485rFIjaKLkalBbjrCJghiD, .
  • 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.
  • the OF1 service 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.
  • 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.
  • 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.
  • Tl and T2 The connection between Tl and T2 involves two functions OF1 and OF2 as described in the COCON frame sent by Tl to T2:
  • the second terminal T2 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.
  • DATA function OF1 data
  • RELAY frame ⁇ @ OF2, @ T2 ⁇ , CJghiD, .
  • 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, ).
  • the second terminal T2 On receipt of the GLUE frame (CJghiD, (7), 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).
  • 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.
  • 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.
  • the data received are associated with two TLS collaborative connections on the basis of the CCT table.
  • 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.
  • 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.
  • Figure 8a illustrates an example of the architecture of a terminal for implementing the proposed method.
  • 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.
  • 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.
  • 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.
  • the communications management module 104 is configured for the implementation of the method proposed by a terminal.
  • 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).
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • the function service module 204 is configured for the implementation of the method proposed by a node implementing a function.
  • 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.
  • 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.
  • 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.
  • 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.
  • ASIC application specific integrated circuit
  • FPGA Field Programmable Gâte Array
  • 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.
  • 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").

Landscapes

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

Abstract

Un procédé de communication dans un réseau (11a, 12, 11b), entre un premier terminal (10a) et un deuxième terminal (10b) entre lesquels est établie une première connexion chiffrée pour transmettre des données, est proposé, qui comprend au premier terminal (10a) : mémoriser, en association avec ladite première connexion, au moins une deuxième connexion entre le premier terminal (10a) et le deuxième terminal (10b) via au moins une fonction de traitement intermédiaire destinée à être appliquée entre le premier terminal (10a) et le deuxième terminal (10b) sur au moins une partie desdites données dites éligibles à la deuxième connexion, et un filtre caractérisant lesdites données éligibles à la deuxième connexion, ladite deuxième connexion étant chiffrée entre le premier terminal et ladite fonction de traitement intermédiaire, et envoyer, via ladite deuxième connexion, au moins un message destiné à ladite fonction intermédiaire transportant des données pour le deuxième terminal (10b) correspondant audit filtre, le premier message envoyé au moins comprenant une information selon laquelle lesdites données sont pour le deuxième terminal (10b).

Description

Description
Titre : Procédé de gestion d’une communication entre terminaux dans un réseau de communication, et dispositifs et système pour la mise en œuvre du procédé Domaine technique
[0001] La présente divulgation se rapporte à un procédé de gestion d’une communication entre un premier terminal et un deuxième terminal dans un réseau de communication, ainsi qu’à des dispositifs pour la mise en œuvre de ce procédé. Elle s’applique notamment à la gestion des communications utilisant une connexion chiffrée, comme par exemple une communication selon le protocole QUIC.
Technique antérieure
[0002] Le protocole QUIC décrit dans le projet de spécification de l’Internet Engineering Task Force (IETF) intitulé « QUIC : A UDP-Based Multiplexed and Secure Transport » est un exemple de protocole de transport spécifié par la communauté Internet pour satisfaire les besoins de certaines applications. Le protocole QUIC repose sur le protocole UDP (de l’anglais « User Datagram Protocol ») plutôt que sur le protocole TCP (de l’anglais « Transmission Control Protocol ») car il a pour ambition de réduire les temps de latence généralement observés lors de l’établissement de connexions TCP.
[0003] A la différence du protocole TLS (de l’anglais « Transport Layer Security ») qui est utilisé pour sécuriser des connexions TCP, QUIC ne chiffre pas seulement les données utiles, mais également les informations de contrôle de connexion. Les informations QUIC envoyées en clair sont limitées au strict minimum (par exemple, l’identifiant de connexion). QUIC permet ainsi d’établir des connexions chiffrées de bout en bout.
[0004] Cependant, la spécification du protocole QUIC n’envisage pas de mécanisme de collaboration entre un terminal QUIC (incluant les applications qu’il supporte) et un réseau d’opérateur pour offrir à l’utilisateur une meilleure qualité d’expérience (ou en anglais, QoE, pour « Quality of Expérience »), via par exemple la mise en œuvre dans le réseau de fonctions proposant divers services tels que des services anti-virus, d’inspection de paquets, de traductions d’adresse et de port, etc. En particulier, une telle coopération ne doit pas induire des délais d’établissement de connexion supplémentaires comparés à ceux des connexions qui n’impliquent pas une fonction réseau. [0005] Or, la présence de telles fonctions dans le réseau peut avoir un impact sur le déroulement d’une connexion QUIC.
[0006] Ainsi, les modifications d’adresses ou de numéros de port exécutées par une fonction réseau telle qu’une fonction de translation d’adresse et de port (NAPT, Network Address and Port Translation en anglais) peuvent conduire à une instabilité de la connexion QUIC car le terminal distant doit vérifier à chaque modification que c’est bien le terminal QUIC qui est à l’origine de ladite modification. Les requêtes QUIC utilisées pour cette vérification peuvent être rejetées (à cause d’une politique de « rate-limit ») ou échouer car le terminal n’a pas la connaissance des modifications effectuées sur ses paquets envoyés dans le réseau.
[0007] En outre, du fait du chiffrement des messages, une fonction réseau placé sur le chemin d’une communication QUIC ne peut pas accéder aux données échangées lors de cette communication.
Résumé
[0008] La présente divulgation vient améliorer la situation.
[0009] Selon un premier aspect, il est proposé un procédé de communication dans un réseau, entre un premier terminal et un deuxième terminal entre lesquels est établie une première connexion chiffrée pour transmettre des données, le procédé comprenant au premier terminal : mémoriser, en association avec ladite première connexion, au moins une deuxième connexion entre le premier terminal et le deuxième terminal via au moins une fonction de traitement intermédiaire destinée à être appliquée sur au moins une partie desdites données dites éligibles à la deuxième connexion, et un filtre caractérisant lesdites données éligibles à la deuxième connexion, ladite deuxième connexion étant chiffrée entre le premier terminal et ladite fonction de traitement intermédiaire, et envoyer, via ladite deuxième connexion, au moins un message destiné à ladite fonction intermédiaire transportant des données pour le deuxième terminal correspondant audit filtre, le premier message envoyé au moins comprenant une information selon laquelle lesdites données sont à destination du deuxième terminal.
[0010] Ainsi, le procédé proposé introduit la notion de connexions collaboratives entre deux terminaux, où une pluralité de connexions chiffrées secondaires (deuxièmes connexions au sens du procédé proposé) est associée à une connexion chiffrée principale établie entre les deux terminaux (première connexion au sens du procédé proposé), et peut avantageusement bénéficier de l’exécution de fonctions de traitement offertes par le réseau. Grâce au procédé proposé, les données échangées via la pluralité de connexions établies entre les deux terminaux sont, du point de vue des terminaux, associées à une seule et même connexion, à savoir la connexion principale.
[0011] En fonction du mode de réalisation, les différentes fonctions de traitement peuvent être invoquées en cascade (c’est-à-dire, un même paquet d’une connexion collaborative sera traité par une ou plusieurs fonctions de traitement aussi désignées ici par fonctions OF (Offered Function), selon un ordre d’invocation fourni typiquement par un terminal) ou selon une chronologie spécifique à chaque contexte.
[0012] Le procédé proposé permet, par ce biais, de valoriser le réseau de l’opérateur via l’introduction de fonctions de traitement optimisant l’usage des ressources mobilisées pour l’établissement et la maintenance de connexions chiffrées entre des terminaux, telles que notamment des connexions QUIC. Lesdites fonctions de traitement ne se limitent pas à celles optimisant l’usage des ressources réseau, mais d’autres types de fonctions peuvent être sollicitées telles que des fonctions de détection et de correction d’erreur (FEC, Forwarding Error Correction). L’opérateur de réseau a ainsi la possibilité d’améliorer le niveau de qualité associé à ces connexions tel que perçu par les utilisateurs.
[0013] Il en résulte une simplification de l’utilisation des clients QUIC sur les terminaux, grâce à une collaboration pragmatique avec le réseau.
[0014] En outre, il convient de noter que le niveau de sécurité et de robustesse associé à chaque connexion chiffrée principale est maintenu, les connexions secondaires étant elles- mêmes chiffrées entre chaque fonction de traitement et les terminaux, et le cas échéant entre les fonctions de traitement entre elles lorsque celles-ci sont invoquées en cascade. Aussi, le consentement des terminaux peut être requis pour l’invocation des fonctions de traitement intermédiaires dans une communication collaborative. Ce faisant, seules les fonctions de confiance n’altérant pas le niveau de sécurité d’une connexion sont sollicitées.
[0015] Le procédé proposé permet ainsi avantageusement d’impliquer des fonctions OF dans une communication entre deux terminaux sans induire de latence supplémentaire pour l’échange des données (0-RTT, « Zéro Round Trip Time » en anglais, c’est-à-dire que les données utiles sont transmises dès l’émission du premier paquet utilisé à des fins d’établissement de la connexion) entre ces deux terminaux.
[0016] Le procédé proposé laisse la possibilité aux terminaux de contrôler la sélection de ces fonctions de traitement. Elle introduit une certaine flexibilité dans l’invocation et le retrait de fonctions de traitement ; en particulier, elle rend possible une invocation à la demande de fonctions de traitement dans le réseau.
[0017] En outre, le procédé proposé fournit avantageusement un mécanisme de sélection d’une partie des données d’une connexion QUIC pour lesquelles une ou plusieurs fonctions OF peuvent être invoquées. De même, la direction du trafic à laquelle appliquer la ou les fonctions de traitement peut également être laissée au choix des terminaux.
[0018] Ainsi, dans un ou plusieurs modes de réalisation, une fonction d’inspection du contenu des paquets (DPI, Deep Packet Inspection en anglais) ou une fonction anti-virus peuvent être invoquées sélectivement pour certains paquets, sans pour autant être invoquées pour l’intégralité des paquets échangés lors d’une communication QUIC.
[0019] Dans un ou plusieurs modes de réalisation, une connexion peut multiplexer plusieurs canaux (aussi désignés par « streams » dans le protocole QUIC), sans limitation quant au nombre de canaux multiplexés, quant à leur nature (unidirectionnels ou bidirectionnels), ou encore quant à l’origine de l’établissement de ces canaux (à l’initiative du client ou du serveur). Le procédé proposé offre ainsi la possibilité de choisir sélectivement les canaux d’une connexion bénéficiant de telles ou telles fonctions de traitement. Aussi, un même canal peut impliquer durant une connexion des fonctions différentes, chacune étant invoquée exclusivement pour une partie des données associées à ce même canal.
[0020] Dans un ou plusieurs modes de réalisation, le procédé proposé peut comprendre en outre : envoyer via la première connexion des données à destination du deuxième terminal, données qui ne correspondent pas audit filtre.
[0021] Dans un ou plusieurs modes de réalisation, le procédé proposé peut comprendre en outre : sur réception de données via ladite deuxième connexion, associer lesdites données à ladite première connexion si les données correspondent audit filtre. [0022] On note qu’un terminal peut décider d’envoyer des données via la première connexion même si ces données sont éligibles à la deuxième connexion. Cette décision est locale au terminal (par ex. pilotée par la couche applicative).
[0023] Dans un ou plusieurs modes de réalisation, ledit premier message comprend en outre une clé destinée à être présentée par la fonction intermédiaire (OF) au deuxième terminal, et partagée entre le premier terminal et le deuxième terminal.
[0024] Ce mode de réalisation permet de renforcer la sécurité du mécanisme proposé.
[0025] Dans un ou plusieurs modes de réalisation, le procédé proposé peut comprendre en outre : informer le deuxième terminal, dans au moins un message émis via ladite première connexion à destination du deuxième terminal, de l’utilisation de ladite fonction de traitement intermédiaire pour ladite au moins une partie desdites données.
[0026] Dans un ou plusieurs modes de réalisation, ledit au moins un message informant le deuxième terminal de l’utilisation de ladite fonction de traitement intermédiaire comprend au moins un élément parmi : un identifiant de ladite fonction de traitement intermédiaire ; une clé à présenter par la fonction intermédiaire au deuxième terminal ; ledit filtre caractérisant les données éligibles à ladite deuxième connexion ; au moins un identifiant de connexion éligible à ladite deuxième connexion ; et une information de direction de transmission des données via la deuxième connexion à laquelle ladite fonction de traitement intermédiaire est appliquée.
[0027] Dans un ou plusieurs modes de réalisation, l’utilisation par le premier terminal de ladite deuxième connexion pour envoyer des données au deuxième terminal est conditionnée par la réception par le premier terminal d’un acquittement du deuxième terminal de l’utilisation de ladite fonction de traitement intermédiaire.
[0028] Dans un ou plusieurs modes de réalisation, sur la deuxième connexion, une pluralité de fonctions de traitement intermédiaires peuvent être appliquées sur les données éligibles à la deuxième connexion dans un ordre déterminé et : ledit au moins un message transportant des données pour le deuxième terminal est destiné à la première fonction de traitement intermédiaire devant être appliquée auxdites données éligibles à la deuxième connexion, ledit premier message envoyé comprend en outre une première liste ordonnée selon ledit ordre déterminé identifiant les fonctions de ladite pluralité de fonctions de traitement intermédiaires distinctes de la première fonction, et devant être appliquées sur lesdites données éligibles.
[0029] Dans un ou plusieurs modes de réalisation, ledit premier message envoyé comprend en outre une deuxième liste ordonnée selon ledit ordre déterminé de clés destinées à être présentées par chacune des fonctions de traitement intermédiaires identifiée dans la première liste à la fonction de traitement intermédiaire suivante dans ladite première liste ou, pour la dernière fonction de traitement intermédiaire de la première liste au deuxième terminal, la clé destinée à être présentée au deuxième terminal étant partagée entre le premier terminal et le deuxième terminal.
[0030] Dans un ou plusieurs modes de réalisation, le procédé proposé peut comprendre en outre : informer le deuxième terminal via la première connexion d’une modification affectant G utilisation de ladite fonction de traitement intermédiaire.
[0031] Dans un ou plusieurs modes de réalisation, ladite première connexion est établie entre le premier terminal et le deuxième terminal selon le protocole QUIC ; au moins une dite deuxième connexion est établie selon le protocole TLS entre le premier terminal et le deuxième terminal via au moins une dite fonction intermédiaire apte à déchiffrer les données échangées via ladite deuxième connexion.
[0032] Selon un deuxième aspect, il est proposé un procédé de communication dans un réseau, entre un premier terminal et un deuxième terminal entre lesquels est établie une première connexion chiffrée pour transmettre des données, le procédé comprenant au deuxième terminal : mémoriser, en association avec ladite première connexion, une fonction de traitement intermédiaire destinée à être appliquée entre le premier terminal et le deuxième terminal sur au moins une partie desdites données, un filtre caractérisant ladite au moins une partie des données et une clé partagée avec le premier terminal ; recevoir au moins un premier message en provenance de ladite fonction intermédiaire transportant des données émises par le premier terminal ; vérifier si lesdites données correspondent au filtre mémorisé ; et en cas de correspondance : accepter l’établissement d’une deuxième connexion chiffrée avec la fonction intermédiaire et associer ladite deuxième connexion à la première connexion ; et sur réception de données via ladite deuxième connexion correspondant audit filtre, associer lesdites données à la première connexion. [0033] Dans un ou plusieurs modes de réalisation, ledit premier message comprend en outre une clé présentée par la fonction de traitement intermédiaire au deuxième terminal, l’établissement de la deuxième connexion chiffrée étant accepté si ladite clé reçue correspond à une clé partagée avec le premier terminal.
[0034] Dans un ou plusieurs modes de réalisation, le procédé proposé peut comprendre en outre : envoyer des données vers le premier terminal via ladite deuxième connexion correspondant audit filtre dans un message destiné à la fonction intermédiaire.
[0035] Selon un troisième aspect, il est proposé un procédé de traitement de données transmises dans un réseau entre un premier terminal et un deuxième terminal entre lesquels est établie une première connexion chiffrée, le procédé comprenant, pour un premier dispositif configuré pour mettre en œuvre une première fonction de traitement intermédiaire de données transmises entre le premier terminal et le deuxième terminal sur une deuxième connexion via ledit premier dispositif : recevoir d’un premier dispositif du réseau au moins un premier message destiné au premier dispositif, transportant des données émises par le premier terminal à destination du deuxième terminal, ledit premier dispositif du réseau étant le premier terminal ou un deuxième dispositif configuré pour mettre en œuvre une deuxième fonction de traitement intermédiaire desdites données, la deuxième connexion étant chiffrée entre le premier dispositif et le premier dispositif, ledit premier message comprenant : une première liste ordonnée identifiant au moins un deuxième dispositif du réseau à emprunter par ledit au moins un message pour être acheminé jusqu’au deuxième terminal, ledit au moins un deuxième dispositif étant le deuxième terminal ou au moins un troisième dispositif configuré pour mettre en œuvre une troisième fonction de traitement intermédiaire desdites données ; et une deuxième liste ordonnée comprenant au moins une clé destinée à être présentée par chaque dispositif de la première liste au dispositif suivant dans ladite première liste, la clé destinée à être présentée au deuxième terminal étant partagée entre le premier terminal et le deuxième terminal ; appliquer la première fonction de traitement intermédiaire auxdites données transportées dans ledit au moins un premier message ; mettre à jour la première liste et la deuxième liste ; et envoyer à destination du dispositif suivant identifié dans la première liste, ledit au moins un premier message intégrant la mise à jour des première et deuxième listes, avec les données traitées par la première fonction de traitement intermédiaire et la clé extraite de la deuxième liste destinée à être présentée au dispositif suivant, la deuxième connexion étant chiffrée entre le premier dispositif et le dispositif suivant.
[0036] Dans un ou plusieurs modes de réalisation, le procédé proposé peut comprendre en outre : mémoriser pour la deuxième connexion : une adresse IP source et un numéro de port source utilisés par le premier dispositif intermédiaire pour relayer lesdites données dudit au moins un premier message ; et une adresse IP destination et un numéro de port destination correspondant au dispositif suivant identifié dans la première liste vers lequel lesdites données dudit au moins un premier message sont transmises ; recevoir du premier dispositif au moins un deuxième message destiné au premier dispositif, transportant des données émises par le premier terminal vers le deuxième terminal, dans lequel la première liste est absente ; appliquer la première fonction de traitement intermédiaire auxdites données transportées dans ledit au moins un deuxième message ; envoyer à destination de l’adresse IP destination et du port destination mémorisés, ledit au moins un deuxième message avec les données traitées par la première fonction de traitement intermédiaire.
[0037] Selon un autre aspect, il est proposé un dispositif de communication de données, comprenant un processeur et une mémoire couplée de manière opérationnelle au processeur, dans lequel le processeur est configuré pour la mise en œuvre d’un des modes de réalisation d’un procédé proposé dans la présente description, tel que mis en œuvre à un dispositif premier terminal, à un dispositif deuxième terminal, ou à un dispositif configuré pour mettre en œuvre une fonction de traitement intermédiaire.
[0038] Selon encore un autre aspect, il est proposé un système de communication de données, comprenant un premier terminal, un deuxième terminal, et un dispositif de mise en œuvre d’une ou plusieurs fonctions de traitement intermédiaires, configurés pour la mise en œuvre d’un des modes de réalisation du procédé proposé dans la présente description, tel que mis en œuvre à un dispositif premier terminal, à un dispositif deuxième terminal, et à un dispositif configuré pour mettre en œuvre une fonction de traitement intermédiaire, respectivement.
[0039] Un autre aspect concerne un programme d’ordinateur, chargeable dans une mémoire associée à un processeur, et comprenant des portions de code pour la mise en œuvre d’un des modes de réalisation du procédé proposé dans la présente description lors de l’exécution dudit programme par le processeur. [0040] Un autre aspect concerne un ensemble de données représentant, par exemple par voie de compression ou d’encodage, un programme d’ordinateur tel que proposé dans la présente description.
[0041] Un autre aspect concerne un support de stockage non-transitoire d’un programme exécutable par ordinateur, comprenant un ensemble de données représentant un ou plusieurs programmes, lesdits un ou plusieurs programmes comprenant des instructions pour, lors de l’exécution desdits un ou plusieurs programmes par un ordinateur comprenant un processeur couplé de manière opérationnelle à une mémoire et à une interface entrées/sorties de communication de données, conduire l’ordinateur à gérer une communication entre un premier terminal et un deuxième terminal dans un réseau de communication selon l’un des modes de réalisation du procédé proposé dans la présente description, tel que mis en œuvre à un dispositif premier terminal, à un dispositif deuxième terminal, ou à un dispositif configuré pour mettre en œuvre une fonction de traitement intermédiaire.
Brève description des dessins
[0042] D'autres particularités et avantages de la présente invention apparaîtront dans la description ci-après d'exemples de réalisation non limitatifs, en référence aux dessins annexés, dans lesquels :
Fig. la
[0043] [Fig. la] illustre un exemple de système de communication dans lequel un ou plusieurs modes de réalisation des procédés, dispositifs et systèmes proposés peuvent être mis en œuvre.
Fig. lb
[0044] [Fig. lb] illustre une architecture de référence pour la mise en œuvre du procédé proposé selon un ou plusieurs modes de réalisation.
Fig. 2a
[0045] [Fig. 2a] illustre un exemple de connexions principale et secondaires établies entre deux terminaux selon un ou plusieurs modes de réalisation.
Fig. 2b [0046] [Fig. 2b] illustre un exemple de connexions principale et secondaires établies entre deux terminaux selon un ou plusieurs modes de réalisation.
Fig. 2c
[0047] [Fig. 2c] illustre la corrélation d’une connexion collaborative avec le réseau sous- jacent selon un ou plusieurs modes de réalisation.
Fig. 3a
[0048] [Fig. 3a] illustre un exemple de table de connexions collaboratives (CCT) selon un ou plusieurs modes de réalisation.
Fig. 3b
[0049] [Fig. 3b] est un diagramme illustrant le procédé proposé selon un ou plusieurs modes de réalisation.
Fig. 4a
[0050] [Fig. 4a] illustre un exemple de format de trame QUIC COCON selon un ou plusieurs modes de réalisation.
Fig. 4b
[0051] [Fig. 4b] illustre un exemple de table (TRS) de gestion de messages d’information d’utilisation de fonction de traitement intermédiaire selon un ou plusieurs modes de réalisation.
Fig. 4c
[0052] [Fig. 4c] illustre un exemple d’invocation d’une fonction de traitement intermédiaire entre un premier terminal et un deuxième terminal selon un ou plusieurs modes de réalisation.
Fig. 4d
[0053] [Fig. 4d] illustre un exemple de table TRS gérée par un terminal selon un ou plusieurs modes de réalisation.
Fig. 4e [0054] [Fig. 4e] illustre un exemple d’invocation d’une fonction de traitement intermédiaire entre un premier terminal et un deuxième terminal selon un ou plusieurs modes de réalisation.
Fig. 4f
[0055] [Fig. 4f] illustre un exemple d’invocation d’une pluralité de fonctions de traitement intermédiaires entre un premier terminal et un deuxième terminal selon un ou plusieurs modes de réalisation.
Fig. 4g
[0056] [Fig. 4g] illustre un exemple d’invocation d’une pluralité de fonctions de traitement intermédiaires entre un premier terminal et un deuxième terminal selon un ou plusieurs modes de réalisation.
Fig. 4h
[0057] [Fig. 4h] illustre un exemple de format de message COCON(UPDATE) selon un ou plusieurs modes de réalisation.
Fig. 5a
[0058] [Fig. 5 a] est un diagramme illustrant le procédé proposé selon un ou plusieurs modes de réalisation.
Fig. 5b
[0059] [Fig. 5b] illustre un exemple de table de relais de connexions collaboratives (RCCB) selon un ou plusieurs modes de réalisation.
Fig. 6a
[0060] [Fig. 6a] est un diagramme illustrant le procédé proposé au niveau du terminal distant selon un ou plusieurs modes de réalisation.
Fig. 6b
[0061] [Fig. 6b] illustre un exemple de table de flux relayés validés (TRS) selon un ou plusieurs modes de réalisation.
Fig. 6c [0062] [Fig. 6c] est un diagramme illustrant un exemple de procédé de traitement d’une nouvelle connexion secondaire au terminal distant selon un ou plusieurs modes de réalisation
Fig. 6d
[0063] [Fig. 6d] illustre un exemple de procédé de traitement d’un nouveau paquet au terminal distant selon un ou plusieurs modes de réalisation.
Fig. 7a
[0064] [Fig. 7a] illustre un exemple de rejet d’une fonction de traitement intermédiaire selon un ou plusieurs modes de réalisation.
Fig. 7b
[0065] [Fig. 7b] illustre un exemple de rejet d’une fonction de traitement intermédiaire selon un ou plusieurs modes de réalisation.
Fig. 7c
[0066] [Fig. 7c] illustre un exemple de rejet d’une fonction de traitement intermédiaire selon un ou plusieurs modes de réalisation.
Fig. 7d
[0067] [Fig. 7d] illustre un exemple de connexion collaborative réussie selon un ou plusieurs modes de réalisation.
Fig. 7e
[0068] [Fig. 7e] illustre un exemple de connexion collaborative réussie selon un ou plusieurs modes de réalisation.
Fig. 7f
[0069] [Fig. 7f] illustre un exemple de connexion collaborative réussie selon un ou plusieurs modes de réalisation.
Fig. 8a
[0070] [Fig. 8a] illustre un exemple d’architecture d’un terminal selon un ou plusieurs modes de réalisation.
Fig. 8b [0071] [Fig. 8b] illustre un exemple d’architecture d’un relais selon un ou plusieurs modes de réalisation.
Description des modes de réalisation
[0072] Dans la description détaillée ci-après de modes de réalisation de l'invention, de nombreux détails spécifiques sont présentés pour apporter une compréhension plus complète. Néanmoins, l’homme du métier peut se rendre compte que des modes de réalisation peuvent être mis en pratique sans ces détails spécifiques. Dans d’autres cas, des caractéristiques bien connues ne sont pas décrites en détail pour éviter de compliquer inutilement la présente description.
[0073] La présente description fait référence à des fonctions, unités, modules, plateformes, et illustrations de diagrammes des méthodes et dispositifs selon un ou plusieurs modes de réalisation. Chacun des fonctions, modules, plateformes, unités et diagrammes décrits peut être mis en œuvre sous forme matérielle, logicielle (y compris sous forme de logiciel embarqué («firmware»), ou de «middleware»), microcode, ou toute combinaison de ces derniers. Dans le cas d’une mise en œuvre sous forme logicielle, les fonctions, moteurs, unités, modules et/ou illustrations de diagrammes peuvent être mis en œuvre par des instructions de programme d’ordinateur ou du code logiciel, qui peut être stocké ou transmis sur un support lisible par ordinateur, incluant un support non transitoire, ou un support chargé en mémoire d’un ordinateur générique, spécifique, ou de tout autre appareil ou dispositif programmable de traitement de données pour produire une machine, de telle sorte que les instructions de programme d’ordinateur ou le code logiciel exécuté(es) sur l’ordinateur ou l’appareil ou dispositif programmable de traitement de données, constituent des moyens de mise en œuvre de ces fonctions.
[0074] Les modes de réalisation d’un support lisible par ordinateur incluent, de manière non exhaustive, des supports de stockage informatique et des supports de communication, y compris tout support facilitant le transfert d’un programme d’ordinateur d’un endroit vers un autre. Par «support(s) de stockage informatique», on entend tout support physique pouvant être accédé par ordinateur. Les exemples de support de stockage informatique incluent, de manière non limitative, les disques ou composants de mémoire flash ou tous autres dispositifs à mémoire flash (par exemple des clés USB, des clés de mémoire, des sticks mémoire, des disques-clés), des CD-ROM ou autres dispositifs de stockage optique de données, des DVD, des dispositifs de stockage de données à disque magnétique ou autres dispositifs de stockage magnétique de données, des composants de mémoire de données, des mémoires RAM, ROM, EEPROM, des cartes mémoires («smart cards»), des mémoires de type SSD («Solid State Drive»), et toute autre forme de support utilisable pour transporter ou stocker ou mémoriser des données ou structures de données qui peuvent être lues par un processeur d’ordinateur. Les instructions peuvent, selon les modes de réalisation, comprendre du code de tout langage de programmation informatique ou élément de programme informatique.
[0075] De plus, les termes «notamment», «par exemple», «exemple», «typiquement» sont utilisés dans la présente description pour désigner des exemples ou illustrations de modes de réalisation non limitatifs, qui ne correspondent pas nécessairement à des modes de réalisation préférés ou avantageux par rapport à d’autres aspects ou modes de réalisation possibles.
[0076] Par «serveur», on entend dans la présente description tout point de service (virtualisé ou non) ou dispositif opérant des traitements de données, une ou plusieurs bases de données, et/ou des fonctions de communication de données. Par exemple, et de manière non limitative, le terme «serveur» peut faire référence à un processeur physique couplé de manière opérationnelle avec des fonctions de communication, de base de données et de stockage de données associées, ou faire référence à un réseau, un groupe, un ensemble ou un complexe de processeurs et des dispositifs de stockage de données et de mise en réseau associés, ainsi qu’un système d’exploitation et un ou plusieurs système(s) de base de données et des logiciels applicatifs en support des services et fonctions fournies par le serveur.
[0077] Les termes «réseau» et «réseau de communication» tels qu’utilisés dans la présente description font référence à une ou plusieurs liaisons de données qui peuvent coupler ou connecter des dispositifs, éventuellement virtualisés, de manière à permettre le transport de données électroniques entre des systèmes informatiques et/ou des modules et/ou d’autres dispositifs ou équipements électroniques. Un réseau peut comprendre, en tout ou partie, le réseau Internet, un ou plusieurs réseaux locaux (en anglais «Local Area Networks», ou LAN), un ou plusieurs réseaux de type WAN (en anglais «Wide Area Networks»), des connexions de type fdaire, des connexions de type sans fil, de type cellulaire, ou toute combinaison de ces différents réseaux. [0078] Le terme « application » tel qu’utilisé dans la présente description désigne tout outil qui fonctionne et est opéré au moyen d’un ordinateur, pour fournir ou exécuter une ou plusieurs fonction(s) ou tâche(s) pour un utilisateur ou un autre programme applicatif. Pour interagir avec une application, et la contrôler, une interface utilisateur (par exemple une interface graphique, en anglais, « Graphical User Interface » ou GUI) peut être fournie sur l’équipement sur lequel l’application est mise en œuvre.
[0079] Le terme « terminal » est utilisé dans la présente description pour désigner tout entité, telle qu’une entité logicielle, capable d’établir ou de recevoir des communications reposant sur l’utilisation d’un ou plusieurs protocoles de transport, tel que TCP ou UDP, et/ou toute entité apte à fonctionner comme point d’extrémité d’une communication établie selon les modalités d’un protocole de communication, tel que, de manière non limitative, les protocoles QUIC, UDP, DTLS ou TLS. Pour une communication donnée, un terminal qui met en œuvre un protocole de communication peut agir en tant que client, serveur, ou les deux. Les exemples de terminaux incluent, de manière non limitative, des terminaux fixes ou mobiles, des terminaux intelligents (en anglais, « smartphones »), des ordinateurs personnels (en anglais, « Personal Computer » ou « PC »), des tabletes, des serveurs du réseau Internet, etc. Certaines décisions liées à l’établissement et à la gestion des communications peuvent être prises par le terminal ou par l’une des applications embarquées dans le terminal, et qui a la capacité d’exploiter les ressources QUIC. La présente description concerne les deux cas : celui où les décisions sont prises par le terminal, et celui où les décisions sont prises par une application embarquée dans ce terminal.
[0080] Le terme « paquet », tel qu’utilisé dans la présente description, désigne de manière non limitative toute unité de données susceptible d’être transportée ou transmise entre deux nœuds de réseau, deux stations, deux terminaux, ou au travers d’un ou plusieurs réseaux de données. Un « paquet » peut désigner une ou plusieurs trames, une ou plusieurs unités de données de protocole (en anglais, « Protocol Data Unit », ou « PDU »), un ou plusieurs datagrammes, ou toute autre unité de données. Un paquet par exemple peut inclure un groupe de bits, qui peut inclure un ou plusieurs champs d’adresse, un ou plusieurs champs de contrôle (ou de signalisation), et/ou un ou plusieurs champs de données utiles.
[0081] Par « fonction », « fonction de traitement intermédiaire », « fonction intermédiaire » ou « fonction réseau », on entend toute fonction de traitement de paquets telle qu’une fonction de traduction d’adresse (NAT), une fonction destinée à améliorer la qualité de service (par ex. une fonction de marquage et de classification de trafic), une fonction pare-feu, une fonction d’optimisation des communications établies sur le protocole de transport TCP (PEP, Performance Enhancing Proxy), proxy MPTCP, etc.
[0082] Par « protocole QUIC », ou de manière abrégée « QUIC », on entend tout protocole conforme à une version de la spécification du protocole QUIC ou de projet de spécification, tel que le projet de spécification de l’IETF intitulé « QUIC : A UDP-Based Multiplexed and Secure Transport », ou la spécification du protocole « Quick UDP Internet Connections », dit protocole « gQUIC », y compris les versions existantes de ces spécifications ou projets de spécifications et leurs évolutions. Plus généralement, QUIC dénote ici tout protocole de transport encapsulé sur un autre protocole de transport UDP ou UDP-lite (de l’anglais « Lighweight User Datagram Protocol ») mais dont les primitives et la charge utile sont chiffrées.
[0083] Bien que les exemples de modes de réalisation décrits ci-dessous reposent sur des communications établies selon le protocole QUIC, l’homme du métier pourra comprendre que ces exemples ne sont pas limitatifs, en ce que le procédé proposé peut également être mis en œuvre, dans d’autres modes de réalisation, en utilisant d’autres protocoles pour établir une communication chiffrée (DTLS ou TLS, par exemple).
[0084] Dans un ou plusieurs modes de réalisation, la logique de sélection des connexions, des paquets, et des canaux (ou « streams ») QUIC éligibles pour solliciter au moins une fonction de traitement intermédiaire est fournie à un terminal sous la forme de politiques. La logique du retrait d’une fonction OF d’une connexion est une politique qui peut être locale au terminal ou bien à l’initiative de l’opérateur, par exemple dans le cadre d’une procédure de maintenance programmée. Ces politiques peuvent être gérées directement par l’application reposant sur les ressources d’une connexion collaborative.
[0085] On suppose qu’un ou plusieurs chemins peuvent être utilisés pour échanger des données entre deux terminaux. Ainsi, les données associées à des canaux différents peuvent être acheminées via un seul chemin ou via des chemins distincts. Aucune hypothèse n’est faite quant au support des fonctions d’établissement des communications QUIC via des chemins multiples par les terminaux ni quant à l’existence de ces chemins multiples. [0086] La figure la illustre un exemple de système de communication (10) dans lequel un ou plusieurs modes de réalisation des procédés et dispositifs proposés peuvent être mis en œuvre.
[0087] Le système (10) comprend un premier terminal Tl (10a) qui a établi une connexion avec un deuxième terminal T2 (10b) par l’intermédiaire d’un premier réseau d’accès (1 la) auquel le premier terminal est connecté, du réseau Internet (12), et d’un deuxième réseau d’accès (11b), auquel le deuxième terminal T2 (10b) est connecté. A titre d’exemple non limitatif, les premier et deuxième réseaux d’accès (l ia et 11b) peuvent être des réseaux locaux (LAN) dans lesquels les terminaux Tl et T2 sont respectivement présents. L’architecture illustrée sur la figure la n’est pas limitative, notamment en ce que les terminaux Tl et T2 peuvent se connecter à un même réseau d’accès.
[0088] Dans un ou plusieurs modes de réalisation, le premier terminal Tl et le deuxième terminal T2 peuvent être configurés pour établir une ou plusieurs connexions selon un protocole de communication, tel que le protocole QUIC, UDP, DTLS, ou TLS, et par exemple établir une connexion selon ce protocole et échanger des données en utilisant cette connexion. Ladite configuration peut être un comportement par défaut d’un terminal (c.-à- d. aucune configuration explicite supplémentaire n’est requise pour l’activation d’un desdits protocoles de communication).
[0089] La figure lb illustre une architecture de référence pour la mise en œuvre du procédé proposé selon un ou plusieurs modes de réalisation.
[0090] Le système (20) comprend un premier terminal Tl (20a) avec lequel une connexion selon un protocole de communication est établie avec un deuxième terminal T2 (20b) par l’intermédiaire d’un réseau (21) auquel le premier terminal Tl (20a) et le deuxième terminal T2 (20b) sont connectés. Le réseau (21) peut être décomposé en plusieurs sous- réseaux, comme par exemple ceux illustrés dans la figure la.
[0091] A nouveau en référence à la figure la, l’homme du métier comprendra que le procédé proposé n’est pas limité quant au nombre, à la nature, ou à la localisation des fonctions OF intermédiaires qui peuvent être invoquées par un terminal. Les fonctions OF peuvent être hébergées au sein du réseau NI (l ia), N2 (11b), ou de tout autre réseau, y compris par exemple le réseau Internet (12) (typiquement, des centres de données (DC, Data Centers)). [0092] De même, une fonction OF peut être localisée (ou non) sur le chemin par défaut emprunté par la communication établie entre deux terminaux, mais ce n’est pas pour autant que ladite fonction OF est sollicitée systématiquement pour tous les flux. On décrit ci-après des mécanismes de contrôle de l’invocation d’une fonction OF.
[0093] Par exemple, les données nécessitant un transcodage, une inspection des données, une adaptation protocolaire, etc. seront destinées explicitement à être traitées par une fonction OF sur décision d’au moins un terminal impliqué dans une connexion.
[0094] Par exemple, une connexion WebRTC peut impliquer des canaux audio, vidéo, présence, etc. Chacun de ces canaux peut nécessiter des fonctions OF distinctes, et supportées par le réseau.
[0095] Une fonction OF peut être insérée dès l’initialisation de l’établissement d’une communication (par exemple l’établissement d’une connexion), pendant la création d’un canal, ou ultérieurement.
[0096] Comme mentionné précédemment, l’invention permet l’invocation de fonctions OF de traitement intermédiaires en introduisant la notion de connexions collaboratives entre deux terminaux Tl et T2, décrite plus en détail ultérieurement. Dans les modes de réalisation dans lesquels plusieurs connexions sont établies selon un protocole de communication entre deux terminaux Tl et T2, par exemple le protocole QUIC, la première connexion établie entre les deux terminaux selon le protocole QUIC est appelée dans la suite : Connexion Principale (ou en anglais, « Primary Connection »). Cette connexion principale peut être établie directement entre Tl et T2 (c’est à dire, sans invocation de fonction OF comme illustré par la Figure 2a) ou via une fonction OF comme le montre la Figure 2b. Les autres connexions sont appelées : Connexions Secondaires (« Secondary Connections »).
[0097] Les figures 2a et 2b montrent ainsi deux terminaux Tl (30a) et T2 (30b) entre lesquels sont établies plusieurs connexions (dans l’exemple illustré des connexions QUIC).
[0098] La figure 2a montre une connexion principale (31a), établie la première, et deux connexions secondaires (32a et 33a), établies entre les deux terminaux Tl (30a) et T2 (30b). La connexion principale est établie sans invocation de fonction OF, tandis que les deux connexions secondaires sont chacune établie avec invocation d’une fonction intermédiaire (respectivement OF1 et OF2). [0099] La figure 2b montre une connexion principale (31b), établie la première, et deux connexions secondaires (32b et 33b), établies entre les deux terminaux Tl (30a) et T2 (30b). La connexion principale est établie avec invocation de fonction OF, de même que les deux connexions secondaires qui sont chacune établie avec invocation d’une fonction (respectivement OF1 et OF2).
[0100] Sur chacun des exemples illustrés par les figures 2a et 2b, les données échangées via la connexion principale sont véhiculées dans des canaux indexés par {a..x}, alors que les données échangées via une connexion secondaire sont acheminées dans les canaux indexés ici par {i...j} ou par {s...t}. Ainsi, {a..x} est une liste d’ identifiants de canaux principaux, alors que {i...j} (ou {s...t}) est une liste de canaux secondaires. Les données appartenant à certains des canaux principaux {a..x} peuvent aussi être éligibles à une connexion secondaire {i..j}. Dès lors, certains identifiants de la liste {a..x} peuvent être présents dans la liste {i..j}, auquel cas, les deux groupes de canaux {a..x} et {i...j} peuvent présenter une intersection non nulle.
[0101] Les données échangées via des connexions secondaires distinctes sont acheminées dans deux canaux {i...j} et {s..t}. Les deux groupes {s..t} et {i...j} peuvent présenter une intersection non nulle, le cas échéant.
[0102] La Figure 2c illustre la corrélation d’une connexion collaborative avec le réseau sous-jacent. Comme illustré dans la figure 2c, les différentes connexions (31c, 32c, 33c), comprenant la connexion principale (31c) et une ou plusieurs connexions secondaires (32c, 33c), peuvent être établies sur un même chemin entre Tl (30a) et T2 (30b).
[0103] On décrit ci-après des exemples de mode de réalisation du procédé proposé de gestion de connexions collaboratives, dans le cas de figure non limitatif de connexions établies selon le protocole QUIC.
[0104] Un premier terminal (par exemple le terminal Tl des figures la - 2c) établit une connexion principale chiffrée avec un deuxième terminal (par exemple le terminal distant T2 des figures la - 2c) selon les modalités décrites dans la spécification QUIC existante.
[0105] Dans un ou plusieurs modes de réalisation, le premier terminal maintient une table de correspondance, appelée dans la suite : Table des connexions collaboratives (« Collaborative Connections Table » (CCT)). [0106] La figure 3 a montre un exemple de structure de table CCT identifiant, pour une connexion principale (Primary Connection Ref), une connexion secondaire collaborative (Secondary Connection Refl), et un filtre caractérisant les données éligibles à cette connexion secondaire collaborative. Par filtre, on entend une indication ou un ensemble d’indications permettant d’identifier les données qui sont éligibles à une connexion secondaire, c’est-à-dire qui peuvent être traitées par la ou les fonctions intermédiaires appartenant à cette connexion secondaire. Il s’agit par le biais de telles indications de « filtrer » les données qui peuvent emprunter la connexion secondaire. Dans l’exemple illustré à la figure 3a, ce filtre se présente sous la forme d’une liste de canaux éligibles, c’est-à-dire pouvant être utilisés pour acheminer les données correspondant à la connexion collaborative, et une liste d’ identifiants de connexion éligibles. Les associations de sécurité (reposant par exemple sur l’utilisation des protocoles TLS/DTLS) pourront être utilisées comme exemples de référence à une connexion. D’autres formats de référence peuvent être utilisés par les différents éléments impliqués dans la procédure.
[0107] Ainsi, une table CCT peut être générée et maintenue en mémoire accessible au premier terminal pour indiquer une liste des canaux/identifiants de connexions éligibles aux connexions collaboratives opérant comme un filtre caractérisant les données éligibles aux connexions collaboratives. Dès lors, même si une fonction est autorisée à établir des connexions secondaires, les données relayées par cette fonction pour des canaux ou présentant des identifiants de connexion non renseignés dans la table CCT pourront être identifiées et éventuellement rejetées par le terminal. La liste des canaux ou la liste des identifiants de connexion sont alimentées par la table TRS (TRUSTED RELAYED STREAMS).
[0108] La figure 3b est un diagramme illustrant le procédé proposé selon un ou plusieurs modes de réalisation.
[0109] On considère des premier et deuxième terminaux, entre lesquels une première connexion chiffrée est établie (50) pour transmettre des données, par exemple selon le protocole QUIC.
[0110] Le premier terminal mémorise (51) ensuite, en association avec ladite première connexion, au moins une deuxième connexion entre le premier terminal et le deuxième terminal via au moins une fonction de traitement intermédiaire destinée à être appliquée entre le premier terminal et le deuxième terminal sur au moins une partie desdites données dites éligibles à la deuxième connexion, et un filtre caractérisant lesdites données éligibles à la deuxième connexion, ladite deuxième connexion étant chiffrée entre le premier terminal et ladite fonction de traitement intermédiaire. Un tel filtre est par exemple un identifiant de connexion, un identifiant de canal ou tout autre gabarit qui permet de sélectionner par un terminal local (ou de déterminer par un terminal distant) les données éligibles à une connexion secondaire. Dans les modes de réalisation décrits ci-après, les identifiant de connexions et de canaux sont utilisés comme des exemples de filtres, et les informations précitées sont mémorisées dans une table CCT telle que décrite précédemment.
[0111] Le procédé proposé permet ainsi avantageusement d’introduire une deuxième connexion entre les deux terminaux entre lesquels une première connexion est déjà établie, via une fonction de traitement intermédiaire, sans pour autant impacter la première connexion, et notamment sans la casser. Les première et deuxième connexions sont collaboratives en ce que les premier et deuxième terminaux gèrent les deux connexions (première et deuxième connexions) comme s’il s’agissait d’une seule connexion globale.
[0112] La mémorisation de cette association entre la première connexion et la deuxième connexion permet d’associer à la première connexion les données qui sont envoyées et reçues sur la deuxième connexion, et correspondant au filtre définissant les données qui sont éligibles à la deuxième connexion.
[0113] La deuxième connexion peut ainsi avantageusement invoquer une ou plusieurs fonctions de traitement intermédiaires, respectivement destinées à être appliquée entre le premier terminal et le deuxième terminal sur les données éligibles à la deuxième connexion.
[0114] Dans un ou plusieurs modes de réalisation, comme illustré sur les figures 2a-2c, la deuxième connexion comprend plusieurs sections (entre le premier terminal et la fonction intermédiaire invoquée dans cette deuxième connexion d’une part, et entre la fonction intermédiaire et le deuxième terminal d’autre part). Par exemple, ce chiffrement est mis en œuvre selon une association de sécurité TLS établies entre les différents dispositifs deux à deux. Lorsque plusieurs fonctions intermédiaires sont invoquées en cascade entre le premier terminal et le deuxième terminal, chaque section est chiffrée individuellement.
[0115] Une fois l’association entre la première connexion et la deuxième connexion mémorisée au premier terminal, le premier terminal peut envoyer (52) via ladite deuxième connexion, au moins un premier message destiné à ladite fonction intermédiaire et transportant des données pour le deuxième terminal correspondant audit filtre, le premier message comprenant une information selon laquelle lesdites données sont destinées au deuxième terminal.
[0116] On donne ci-après des exemples de messages envoyés par le premier terminal.
[0117] Dans un ou plusieurs modes de réalisation, le premier terminal peut sélectionner selon un filtre les paquets (des canaux) qui doivent solliciter une fonction OF, autrement dit qui sont éligibles à la deuxième connexion. Les paquets sélectionnés peuvent être envoyés en utilisant l’adresse qui permet d’accéder à la fonction intermédiaire (OF) comme adresse destination. Les données véhiculées par les paquets sont chiffrées selon l’association de sécurité (par exemple TLS) établie entre le premier terminal et la fonction OF. De plus, dans l’exemple non limitatif dans lequel les connexions entre les deux terminaux sont établies selon le protocole QUIC, les données peuvent transporter une nouvelle trame QUIC appelée
RELAY(List{Next_FIop_IP address/port} , Shared Token, ...), comportant, dans un mode de réalisation, les champs décrits ci-après :
[0118] List{Next_FIop_IP address/port}: Contient une liste d’adresses (et numéros de port) qui sera utilisée par la ou les fonctions intermédiaires OF invoquées dans la deuxième connexion, pour l’acheminement du paquet jusqu’à sa destination finale. Dans un ou plusieurs modes de réalisation, cette liste contient l’adresse IP (et éventuellement un numéro de port) du deuxième terminal (terminal distant) si une seule fonction OF est sollicitée dans le chemin emprunté par les données. Si plusieurs fonctions sont sollicitées, alors ladite liste est une liste ordonnée qui comporte, outre des informations permettant de joindre le terminal distant, des informations descriptives des fonctions intermédiaires OF qui doivent être invoquées. Le premier élément de ladite liste ordonnée pointe vers la prochaine fonction OF à invoquer alors que le dernier élément pointe vers le terminal distant.
[0119] « Shared Token » : Indique une clé à présenter pour le prochain saut. Dans un ou plusieurs modes de réalisation, une même clé peut être utilisée. En variante, le message peut contenir une liste ordonnée de clés : List{Next_Hop_Shared Token}. Une clé de la position « i » sera présentée à l’élément « i » de la liste List{Next_Hop_IP address/port}. Ainsi, dans un ou plusieurs modes de réalisation, le message envoyé par le premier terminal pourra comprendre une deuxième liste, ordonnée selon l’ordonnancement de la (première) liste de fonctions, de clés destinées à être présentées par chacune des fonctions de traitement intermédiaires identifiée dans la première liste à la fonction de traitement intermédiaire suivante dans ladite première liste ou, pour la dernière fonction de traitement intermédiaire de la première liste au deuxième terminal, la clé destinée à être présentée au deuxième terminal étant partagée entre le premier terminal et le deuxième terminal. Dans un ou plusieurs modes de réalisation, les clés ne peuvent être présentes que pour le premier paquet de données envoyé dans une nouvelle connexion secondaire, et peuvent dès lors être omises pour les autres paquets.
[0120] Ainsi, dans un ou plusieurs modes de réalisation, le premier message envoyé par le premier terminal via la deuxième connexion peut comprendre une clé destinée à être présentée par la fonction intermédiaire au deuxième terminal, et partagée entre le premier terminal et le deuxième terminal.
[0121] Dans un ou plusieurs modes de réalisation, le premier terminal peut décider de n’inclure la trame RELAY que pour les premiers paquets envoyés vers une fonction OF (c’est-à-dire dans les premiers messages envoyés à la fonction OF). Les autres paquets éligibles sont envoyés directement à la fonction OF (c’est-à-dire, sans insertion de trame RELAY) qui doit les traiter en utilisant une table dédiée (appelée, RCCB), décrite ci- dessous.
[0122] Pour les autres paquets, c’est-à-dire pour les paquets qui ne sont pas éligibles à un traitement par une fonction OF (autrement dit pour les paquets ne correspondant pas au filtre associé à la connexion secondaire établie via cette fonction OF), les données sont envoyées, dans le mode de réalisation décrit ici, directement par le premier terminal au deuxième terminal via la première connexion (la connexion principale). On note que si plusieurs connexions secondaires sont envisagées, si des données correspondent à un filtre d’une autre connexion secondaire, elles seront préférentiellement envoyées au deuxième terminal via cette autre connexion secondaire.
[0123] Au cours de la première connexion, le premier terminal peut décider d’insérer la fonction de traitement intermédiaire OF pour tout ou partie des canaux de ladite connexion établie avec le deuxième terminal, par exemple pour une partie des données émises à destination du deuxième terminal. [0124] Le premier terminal peut informer le deuxième terminal de G utilisation de la fonction de traitement intermédiaire pour une partie des données, par l’émission d’un message d’information d’utilisation d’une fonction OF émis via la première connexion à destination du deuxième terminal.
[0125] Le message d’information d’utilisation d’une fonction OF permet avantageusement d’informer un terminal distant avec lequel une première connexion chiffrée est établie de l’utilisation d’une fonction de traitement intermédiaire pour tout ou partie des données transmises ou échangées avec ce terminal distant, en indiquant éventuellement au terminal distant une information concernant un critère d’éligibilité des données pour l’invocation de la fonction tel qu’utilisé par le premier terminal (autrement dit, en lui indiquant un filtre caractérisant les données éligibles).
[0126] Dans un ou plusieurs modes de réalisation, le message d’information d’utilisation d’une fonction OF informant le deuxième terminal de l’utilisation de la fonction de traitement intermédiaire pourra comprendre au moins un élément parmi : un identifiant de la fonction de traitement intermédiaire ; une clé à présenter par la fonction intermédiaire au deuxième terminal ; le filtre caractérisant les données éligibles à la deuxième connexion ; au moins un identifiant de connexion éligible à la deuxième connexion ; et une information de direction de transmission des données via la deuxième connexion sur laquelle ladite fonction de traitement intermédiaire est appliquée.
[0127] Par exemple, dans l’exemple non limitatif dans lequel la première connexion entre les deux terminaux est établie selon le protocole QUIC, le premier terminal peut, dans un ou plusieurs modes de réalisation, insérer une nouvelle trame QUIC, appelée COCON (COllaborative CONnection), dans un message de contrôle ou un message de données de la première connexion (connexion principale) à destination du terminal distant.
[0128] La figure 4a illustre un exemple de format de trame QUIC COCON, dont les champs sont décrits ci-après :
[0129] Un bit « D » d’indication de direction: Ce bit peut par exemple être positionné à « 0 » (respectivement à « 1 ») si la fonction de traitement intermédiaire est insérée uniquement pour les données émises par le premier terminal (ayant émis la trame COCON vers le deuxième terminal), et être positionné à « 1 » (respectivement à « 0 ») si la fonction peut être utilisée pour les deux directions de la connexion. [0130] « Third Party ID » : Indique un identifiant (globalement) unique identifiant une fonction de traitement intermédiaire (OF). Dans un ou plusieurs modes de réalisation, cet identifiant peut être un « hash » (obtenu en utilisant l’algorithme SHA-256, par exemple) de l’information "Pre-Shared Key (PSK) identity" utilisée par la fonction OF dans un message TLS « ClientKeyEx change ». D’autres structures peuvent être utilisées pour cet identifiant.
[0131] « Shared Token » : Une clé partagée entre la fonction de traitement intermédiaire (OF) et le terminal émetteur de la trame.
[0132] « List Stream IDs » : Un filtre qui liste un ou plusieurs identifiants respectifs d’un ou plusieurs canaux éligibles à l’invocation de la fonction de traitement intermédiaire (OF) identifiée par le champ « Third Party ID ». Dans un ou plusieurs modes de réalisation, ce champ peut être défini en incluant un cas de figure dans lequel ce champ ne contient aucun identifiant de canal, pour indiquer que la fonction peut être invoquée pour l’ensemble des canaux d’une connexion (c’est-à-dire, tous les paquets de ladite connexion sont éligibles pour invoquer la fonction OF).
[0133] « List Connection ID » : Un filtre qui liste un ou plusieurs identifiants de connexion éligibles pour l’invocation de la fonction de traitement intermédiaire OF identifiée par le champ « Third Party ID ». Dans un ou plusieurs modes de réalisation, ce champ peut être défini en incluant un cas de figure dans lequel ce champ ne contient aucun identifiant de connexion, pour indiquer que la fonction peut être invoquée pour l’ensemble des identifiants de connexions associés à cette connexion. Dans un ou plusieurs modes de réalisation, la liste des identifiants de connexions indiqués dans un message d’information d’utilisation de fonction (par exemple une trame COCON) peut être mise à jour automatiquement par un terminal distant suite à la migration d’ identifiants de connexion (par exemple, suite à la réception d’une trame QUIC NEW_CONNECTION).
[0134] Dans un ou plusieurs modes de réalisation, si aucune restriction de direction n’est indiquée dans le message d’information d’utilisation de fonction OF, la direction de l’invocation de la fonction peut être déduite sur la base de la direction du canal associé. Dans le cas du protocole QUIC par exemple, les bits de poids faible du « stream ID » indiquent la nature du canal : 0x0 (canal bidirectionnel établi à l’initiative du client), 0x1 (canal bidirectionnel établi à l’initiative du serveur), 0x2 (canal unidirectionnel établi à l’initiative du client) et 0x3 (canal unidirectionnel établi à l’initiative du serveur). [0135] Dans un ou plusieurs modes de réalisation, plusieurs messages d’information d’utilisation de fonction OF (par exemple des trames COCON) peuvent être envoyés si le premier terminal décide d’impliquer une fonction de traitement intermédiaire OF dans des canaux différents.
[0136] Dans un ou plusieurs modes de réalisation, plusieurs messages d’information d’utilisation de fonction OF (par exemple des trames COCON) peuvent être envoyés si le premier terminal décide d’impliquer plusieurs fonctions de traitement intermédiaire OF.
[0137] Dans un ou plusieurs modes de réalisation, un message d’information d’utilisation de fonction OF (par exemple une trame COCON) peut être envoyé dans n’importe quel message d’une connexion, y compris le premier message d’établissement de connexion.
[0138] Dans un ou plusieurs modes de réalisation, une fonction de traitement intermédiaire OF peut être embarquée dans un nœud localisé sur le chemin d’acheminement des données par défaut (ou pas).
[0139] Dans un ou plusieurs modes de réalisation, le premier terminal utilise une table dédiée TRS, pour enregistrer les offres envoyées (c’est-à-dire, la caractérisation des données (éligibles) qui bénéficient de l’invocation d’une ou plusieurs fonctions OF selon les informations véhiculées dans les trames COCON et qui ont conduit à la création d’entrées dans la table TRS).
[0140] Dans un ou plusieurs modes de réalisation, le premier terminal peut utiliser une table gérant les entrées correspondant aux trames COCON envoyées à un terminal distant (au deuxième terminal) et une autre table gérant les entrées correspondant aux trames COCON reçues du terminal distant. En variante, une même table peut être utilisée quelle que soit l’origine des trames COCON.
[0141] La Figure 4b illustre un exemple d’une table gérant les entrées correspondant aux messages d’information d’utilisation de fonction de traitement intermédiaire envoyées vers le deuxième terminal selon un ou plusieurs modes de réalisation. Les messages, qui correspondent à des offres d’utilisation de fonction OF, sont associées à une connexion principale (dénommée « Primary Connection Ref »).
[0142] La figure 4b montre un exemple de structure de table TRS (« Primary Connection Ref Out » pour les offres envoyées pour la connexion principale « Primary Connection Ref »), qui contient les informations suivantes : [0143] « OF ID » : un identifiant d’une fonction OF.
[0144] « Direction » : dans un ou plusieurs modes de réalisation, ce champ indique une première valeur indiquant une utilisation de la fonction identifiée par le champ OF ID unidirectionnelle à l’initiative du premier terminal, c’est-à-dire pour des données envoyées par le premier terminal, une deuxième valeur indiquant une utilisation de la fonction identifiée par le champ OF ID unidirectionnelle à l’initiative du deuxième terminal, c’est- à-dire pour des données envoyées par le deuxième terminal, ou une troisième valeur indiquant une utilisation de la fonction identifiée par le champ OF ID bidirectionnelle, c’est-à-dire pour des données envoyées par le premier terminal ou par le deuxième terminal. Par exemple, ce champ peut indiquer l’une des valeurs suivantes : 0 (Unidirectionnel à l’initiative du terminal), 1 (Unidirectionnel à l’initiative du terminal distant), 2 (bidirectionnel).
[0145] « Token » : Une clé de vérification qui doit être présentée (par une fonction OF) pour établir une nouvelle connexion secondaire associée à une connexion principale.
[0146] Liste des « Stream IDs » : Un filtre qui liste les canaux dont les données peuvent être relayées par la fonction identifiée dans le champ OF ID (c’est-à-dire les canaux éligibles). Dans un ou plusieurs modes de réalisation, une valeur prédéterminée (par exemple dénommée « Any ») peut être utilisée pour indiquer que la fonction peut être invoquée par tous les canaux d’une connexion.
[0147] List des « Connection IDs » : Un filtre qui liste les identifiants de connexion dont les données font l’objet d’un traitement par la fonction identifiée dans le champ OF ID (c’est-à-dire les identifiants de connexions éligibles). Dans un ou plusieurs modes de réalisation, une valeur prédéterminée (par exemple dénommée « Any ») peut être utilisée pour indiquer que la fonction peut être invoquée pour n’importe quel identifiant d’une connexion.
[0148] « Status » : Indique si la proposition d’invoquer une ou plusieurs fonctions OF selon les informations véhiculées dans une trame COCON est confirmée par le terminal distant, ou si la proposition est en attente de confirmation du terminal distant. Ce champ peut être limité à un seul bit, qui prendra une première valeur (par exemple « 1 », correspondant à « Confirmed ») pour indiquer une proposition d’utilisation de fonction validée par le deuxième terminal, et une deuxième valeur (par exemple « 0 », correspondant à « Pending ») pour indiquer que la proposition d’utilisation de fonction est en attente de validation par le deuxième terminal. Dans un ou plusieurs modes de réalisation, ce champ peut être positionné à la valeur d’attente de confirmation (« Pending ») tant qu’un message de confirmation n’a pas été reçu de la part du deuxième terminal. Le message de confirmation est typiquement un message d’acquittement envoyé par le deuxième terminal suite à la réception du message d’information d’utilisation de fonction de traitement intermédiaire (par exemple suite à la réception d’une trame COCON).
[0149] Dans un ou plusieurs modes de réalisation, l’utilisation par le premier terminal de la deuxième connexion pour envoyer des données au deuxième terminal peut être conditionnée par la réception par le premier terminal d’un acquittement en provenance du deuxième terminal pour G utilisation de la fonction intermédiaire. Le premier terminal peut ainsi être configuré pour ne pas envoyer les données via une connexion secondaire où une fonction intermédiaire (OF) sera invoquée pour laquelle le paramètre « Status » est positionné à une valeur indiquant une attente de confirmation du deuxième terminal.
[0150] En variante, le message de confirmation est un message appelé
GLUE (Confirmed, ...) décrit ci-après. Dans ce cas, le terminal peut envoyer les premiers paquets via la fonction OF même si le paramètre « Status » est positionné à « 0 ». Le terminal avisera en fonction de la réponse du terminal distant (typiquement, le terminal continuera de solliciter la fonction OF si et seulement si un message
GLUE (Confirmed, ...) a été reçu.).
[0151] La figure 4c illustre un exemple d’invocation d’une fonction de traitement intermédiaire (OF1) entre un premier terminal Tl (60a) et un deuxième terminal T2 (60b).
[0152] En référence à l’exemple illustré par la figure 4c (qui reprend l’architecture de référence illustrée par la figure lb), les terminaux Tl (60a) et T2 (60b) sont en communication via un réseau (63) et maintiennent trois canaux (62a, 62b, 62c) de communication de données utilisant une connexion chiffrée : Le premier canal (62a) est un canal unidirectionnel de Tl à T2, c’est-à-dire que seul Tl peut envoyer des données dans ce canal. Le deuxième canal (62b) est un canal bidirectionnel entre Tl et T2. Les terminaux Tl et T2 peuvent envoyer des données dans ce canal qui n’invoque pas de fonction OF. Le troisième canal (62c) est un canal unidirectionnel de T2 à Tl. Seul T2 peut envoyer des données dans ce canal qui n’invoque pas de fonction OF. [0153] Dans cet exemple, les données des différents canaux (62a, 62b, 62c) sont acheminées via le même chemin.
[0154] Le terminal Tl peut impliquer la fonction OF1 dans le premier canal (62a), alors que les données des autres canaux sont échangées directement entre Tl et T2. Pour ce faire, dans un ou plusieurs modes de réalisation, le terminal Tl (60a) insère une trame COCON(D=0, OF1, mytoken, streaml id) dans un message à destination du terminal T2 (60b) : direction du terminal Tl vers le terminal T2 (D=0), fonction d’ identifiant OF1, clé « mytoken », identifiant de canal « streaml id » correspondant au premier canal.
[0155] Comme décrit ci-dessus, dans un ou plusieurs modes de réalisation, le terminal Tl (60a) peut être configuré pour gérer une table d’offres d’utilisation de fonctions OF pour la connexion principale avec le terminal T2 (60b) (table TRS), et instancier une entrée dans sa table TRS relativement à la trame COCON transmise au terminal T2 (60b), comme illustré sur la figure 4d.
[0156] La figure 4d montre un exemple de table TRS gérée par le terminal Tl, dans laquelle sont consignées des informations relatives à la trame COCON(D=0, OF1, mytoken, streaml id) envoyée au terminal T2 : identifiant de la fonction (« OF ID ») objet de l’offre d’utilisation (« OF1 »), direction d’utilisation de la fonction OF1 (champ « Direction ») indiquant un sens unidirectionnel à l’initiative du terminal Tl (valeur « 0 »), clé de vérification (champ « Token » renseigné avec la clé « myToken »), liste des canaux dont les données peuvent être relayées par la fonction OF1 (« List Stream IDs ») indiquant un identifiant du premier canal (62a) (« streaml id »), liste des identifiants de connexion dont les données font l’objet d’un traitement par la fonction OF1 (« List Connection IDs ») indiquant que la fonction OF1 peut être utilisée pour tout identifiant de connexion (« Any »), et statut de l’offre d’utilisation de la fonction OF1 (« Status ») indiquant que l’offre est en attente de validation par le terminal distant T2 (60b).
[0157] La figure 4e illustre un autre exemple d’invocation de deux fonctions de traitement intermédiaire (OF1 et OF2) entre un premier terminal Tl (60a) et un deuxième terminal T2 (60b).
[0158] En référence à l’exemple de la figure 4e (qui reprend l’architecture de référence de la figure lb), les terminaux Tl (60a) et T2 (60b) sont en communication via un réseau (63) et maintiennent trois canaux (62a, 62b, 62c) de communication de données utilisant une connexion chiffrée : Le premier canal (62a) est un canal unidirectionnel de Tl à T2, le deuxième canal (62b) est un canal bidirectionnel entre Tl et T2, et le troisième canal (62c) est un canal unidirectionnel de T2 à Tl. Dans cet autre exemple, les données des différents canaux (62a, 62b, 62c) sont aussi acheminées via le même chemin.
[0159] A la différence de l’exemple de la figure 4c, la figure 4e illustre un exemple dans lequel une première fonction OF1 (61a) est invoquée pour les deux premiers canaux (62a et 62b), tandis qu’une deuxième fonction OF2 (61b) est invoquée pour les données du troisième canal (62c). Pour ce faire, dans un ou plusieurs modes de réalisation, le terminal Tl (60a) peut insérer une trame COCON(OFl, mytoken, (streaml id, stream2_id}, ...) dans un message à destination du terminal T2 (60b), et le terminal T2 (60b) peut insérer une trame COCON(OF2, myowntoken, stream3_id, ...) dans un message à destination du terminal Tl (60a). Dans ces exemples de trame COCON, la direction n’est pas indiquée, et le terminal distant pourra utiliser la direction du canal associé pour déduire la valeur du bit de direction « D ».
[0160] La trame COCON(OFl, mytoken, (streaml id, stream2_id}, ...) pourra comporter les informations suivantes : fonction d’ identifiant OF1, clé « mytoken », identifiants de canal « streaml id » et « stream2_id » correspondant respectivement au premier canal et au deuxième canal. La trame COCON(OF2, myowntoken, stream3_id, ...) pourra comporter les informations suivantes : identifiant de fonction OF2, clé « myowntoken », identifiant de canal « stream3_id » correspondant au troisième canal.
[0161] Dans un ou plusieurs modes de réalisation, des fonctions OF distinctes peuvent être invoquées en fonction de la direction de trafic. Typiquement, un canal bidirectionnel peut impliquer des fonctions distinctes par sens du trafic. En référence à l’exemple de la figure 4f (qui reprend l’architecture de référence de la figure lb), les terminaux Tl (60a) et T2 (60b) sont en communication via un réseau (63) et utilisent un canal de communication de données bidirectionnel reposant sur une connexion chiffrée : Comme illustré par la figure 4f, un canal bidirectionnel peut donc impliquer une fonction OF1 (61a) pour les données du canal envoyées par le terminal Tl (60a), alors que les données du canal envoyées par le terminal T2 (60b) seront traitées par OF2 (61b). Pour ce faire, dans un ou plusieurs modes de réalisation, le terminal Tl (60a) peut insérer une trame COCON(D=0, OF1, myTltoken, streaml id, ...) dans un message à destination du terminal T2 (60b), et le terminal T2 (60b) peut insérer une trame COCON(D=l, OF2, myT2token, streaml id, ...) dans un message à destination du terminal Tl (60a).
[0162] La trame COCON(D=0, OF1, myTltoken, streaml id, ...) pourra comporter les informations suivantes : direction du terminal Tl vers le terminal T2 (D=0), fonction d’identifiant OF1, clé « mytoken », identifiant de canal « streaml id » correspondant au canal. La trame COCON(D=0, OF2, myT2token, streaml id, ...) pourra comporter les informations suivantes : direction du terminal T2 vers le terminal Tl (D=0), identifiant de fonction OF2, clé « myT2token », identifiant de canal « streaml id » correspondant au même canal.
[0163] Dans un ou plusieurs modes de réalisation, le premier message transportant des données pour le deuxième terminal peut être destiné à la première fonction de traitement intermédiaire parmi une pluralité de fonctions de traitement intermédiaires devant être appliquées sur les données éligibles à la deuxième connexion dans un ordre déterminé. Ce premier message peut en outre comprendre une première liste ordonnée, par exemple selon l’ordre déterminé d’application des fonctions, identifiant les fonctions de la pluralité de fonctions de traitement intermédiaires distinctes de la première fonction devant être appliquées sur lesdites données éligibles.
[0164] Ces modes de réalisation du procédé proposé permettent avantageusement de traiter le cas de figure dans lequel plusieurs fonctions de traitement intermédiaires doivent être invoquées pour un même paquet d’une connexion donnée.
[0165] Dans un ou plusieurs modes de réalisation dans lesquels une pluralité de fonctions de traitement intermédiaires doit être invoquée pour un même paquet d’une connexion donnée, le premier terminal peut ne communiquer au deuxième terminal (terminal distant) que l’identité de la dernière fonction OF à être invoquée lors de l’acheminement d’un paquet vers le terminal distant. En référence à l’exemple de la figure 4g (qui reprend l’architecture de référence de la figure lb), les terminaux Tl (60a) et T2 (60b) sont en communication via un réseau (63) et communiquent via trois canaux (62a, 62b, 62c) de communication de données sur une connexion chiffrée : Le premier canal (62a) est un canal unidirectionnel de Tl à T2, le deuxième canal (62b) est un canal bidirectionnel entre Tl et T2, et le troisième canal (62c) est un canal unidirectionnel de T2 à Tl. Dans l’exemple de la figure 4g, le terminal Tl (60a) peut insérer une trame
COCON(D=l, OF3, mytoken, stream2_id, ...) dans un message à destination du terminal T2 (60b). La trame COCON(D=l, OF3, mytoken, stream2_id, ...) pourra comporter les informations suivantes : direction du terminal Tl vers le terminal T2 (D=l), identifiant de fonction OF3 correspondant à la dernière fonction parmi la suite ordonnée de fonctions OF1, OF2, et OF3 (61a, 61b, 61c) à être invoquées pour les données transmises sur le deuxième canal (62b), clé « mytoken », et identifiant de canal « stream2_id » correspondant au deuxième canal.
[0166] Dans un ou plusieurs modes de réalisation, le premier terminal pourra être configuré pour informer le deuxième terminal, via la connexion principale, d’une modification affectant l’utilisation d’une fonction de traitement intermédiaire.
[0167] Par exemple, dans un ou plusieurs modes de réalisation, le premier terminal peut être configuré pour informer le deuxième terminal (terminal distant) de la mise à jour de la politique d’insertion d’une ou plusieurs fonctions OF en envoyant un message COCON(UPDATE) dont le format est illustré par la Figure 4h.
[0168] Dans un ou plusieurs modes de réalisation, la description des champs de cette trame peut être identique à celle des champs de la trame COCON, à l’exception des champs suivants :
[0169] « List disabled Stream IDs » : Indique la liste des canaux pour lesquels il ne faut plus accepter les connexions secondaires désormais. Ces identifiants de canaux doivent être exclus du filtre utilisé pour déterminer les données éligibles à une connexion secondaire.
[0170] « List disabled Connection IDs » : Indique la liste des identifiants de connexion qu’il ne faut plus accepter désormais. Ces identifiants de connexion doivent être exclus du filtre utilisé pour déterminer les données éligibles à une connexion secondaire.
[0171] Par exemple, le premier terminal peut utiliser la trame COCON(UPDATE) pour mettre fin à l’invocation d’une fonction OF, pour mettre à jour la liste des canaux éligibles au service fourni par une fonction OF, et/ou pour mettre à jour la liste des identifiants de connexions éligibles au service fourni par une fonction OF.
[0172] Dans un ou plusieurs modes de réalisation, la connexion principale pourra être établie entre le premier terminal et le deuxième terminal selon le protocole QUIC, et une ou plusieurs connexions secondaires pourront être établies entre le premier terminal et le deuxième terminal, chacune via une ou plusieurs fonctions intermédiaires établies selon le protocole TLS.
[0173] La figure 5a est un diagramme illustrant le procédé proposé selon un ou plusieurs modes de réalisation, du point de vue d’une fonction intermédiaire.
[0174] Selon un aspect, le procédé proposé se rapporte au traitement de données transmises dans un réseau entre un premier terminal et un deuxième terminal entre lesquels est établie une première connexion chiffrée, effectué par un premier dispositif configuré pour mettre en œuvre une première fonction de traitement intermédiaire de données transmises entre le premier terminal et le deuxième terminal sur une deuxième connexion via le premier dispositif.
[0175] Dans un ou plusieurs modes de réalisation, ce premier dispositif peut être configuré pour recevoir (70) d’un premier dispositif du réseau au moins un premier message destiné au premier dispositif, transportant des données émises par le premier terminal pour le deuxième terminal, ledit premier dispositif du réseau étant le premier terminal ou un deuxième dispositif configuré pour mettre en œuvre une deuxième fonction de traitement intermédiaire desdites données, la deuxième connexion étant chiffrée entre le premier dispositif et le premier dispositif, ledit premier message comprenant : une première liste ordonnée identifiant au moins un deuxième dispositif du réseau à emprunter par ledit au moins un message pour être acheminé jusqu’au deuxième terminal, ledit au moins un deuxième dispositif étant le deuxième terminal ou au moins un troisième dispositif configuré pour mettre en œuvre une troisième fonction de traitement intermédiaire desdites données, et une deuxième liste ordonnée comprenant au moins une clé destinée à être présentée par chaque dispositif de la première liste au dispositif suivant dans ladite première liste, la clé destinée à être présentée au deuxième terminal étant partagée entre le premier terminal et le deuxième terminal.
[0176] Le premier dispositif, qui est configuré pour la mise en œuvre de la première fonction de traitement intermédiaire, peut, sur réception du premier message, appliquer (71) la première fonction de traitement intermédiaire aux données transportées dans le premier message.
[0177] Dans un ou plusieurs modes de réalisation, ce premier dispositif peut en outre mettre à jour (72) la première liste et la deuxième liste reçues avec le premier message. [0178] Dans un ou plusieurs modes de réalisation, ce premier dispositif peut ensuite envoyer (73), à destination du dispositif suivant identifié dans la première liste, le premier message intégrant la mise à jour des première et deuxième listes, avec les données traitées par la première fonction de traitement intermédiaire et la clé extraite de la deuxième liste destinée à être présentée au dispositif suivant, la deuxième connexion étant chiffrée entre le premier dispositif et le dispositif suivant.
[0179] Comme discuté ci-dessus, dans les modes de réalisation dans lesquels la première connexion entre les deux terminaux est établie selon le protocole QUIC, le premier terminal peut insérer une trame QUIC de type RELAY tel que décrit ci-dessus, dans un message de contrôle ou un message de données de la première connexion (connexion principale) à destination du premier dispositif, auquel cas le premier message reçu par le premier dispositif peut être une trame RELAY.
[0180] Ainsi, dans un ou plusieurs modes de réalisation, à réception d’un message contenant une trame QUIC
RELAY(List{Next_Hop_IP address/port} , Shared Token, ...) par un premier dispositif configuré pour la mise en œuvre d’une fonction de traitement intermédiaire (OF):
[0181] Si plusieurs fonctions OF doivent être invoquées, alors la liste List{Next_Hop_IP address/port} peut inclure la liste de toutes les fonctions OF à invoquer, exceptée la première fonction, en plus de l’adresse (et éventuellement, du numéro de port) du terminal distant. Dans ce cas, le message est envoyé par le premier terminal à destination de la première fonction à invoquer, c’est-à-dire à destination du premier dispositif configuré pour mettre en œuvre la première fonction à invoquer dans la suite ordonnée de fonctions à invoquer.
[0182] Ainsi, pour un paquet de données devant traverser plusieurs fonctions de traitement intermédiaires, le premier terminal peut envoyer un message à destination de la première fonction à mettre en œuvre pour le paquet. La première fonction exécute son service pour le paquet, puis détermine des informations permettant d’envoyer le paquet vers la fonction suivante à mettre en œuvre pour le paquet.
[0183] Chaque fonction de traitement intermédiaire OF qui doit être invoquée doit traiter chaque paquet éligible au traitement effectué par la fonction. [0184] Dans un ou plusieurs modes de réalisation, chaque fonction de traitement intermédiaire qui doit être invoquée peut mettre à jour la liste List{Next_Hop_IP address/port} , par exemple en retirant les données « Next_Hop_IP address/port » correspondant à la prochaine fonction de traitement intermédiaire à invoquer de la liste List{Next_Hop_IP address/port}. Le paquet peut ensuite être transmis vers cette prochaine fonction en utilisant les données « Next Hop IP address/port », après avoir instancié une entrée dans une table RELAYED COLLABORATIVE CONNECTIONS BASE (RCCB), comme décrit ci-dessous. La procédure proposée peut être réitérée jusqu’à ce que le paquet soit reçu par la dernière fonction OF à invoquer. Le traitement à effectuer correspond alors au cas de figure dans lequel une seule fonction doit être invoquée.
[0185] Si une seule fonction OF doit être invoquée, alors la liste List{Next_Hop_IP address/port} ne contient que l’adresse (et éventuellement, le numéro de port) du deuxième terminal (terminal distant). Le message est envoyé en utilisant l’adresse IP permettant d’accéder à la fonction OF comme adresse de destination du paquet après l’exécution du service offert par la fonction OF.
[0186] En outre, dans un ou plusieurs modes de réalisation, la fonction OF peut inclure une nouvelle trame QUIC appelée GLUE(Shared_Token, [mylD], ...). En d’autres termes, le paquet récupéré en sortie de la fonction OF peut être chiffré selon une nouvelle association de sécurité à établir entre la fonction OF et le deuxième terminal. Dans un ou plusieurs modes de réalisation, la fonction OF peut à cette occasion instancier une entrée dans la table RCCB. Par ailleurs, l’envoi du premier paquet (premier message) peut par exemple reposer sur le mécanisme 0-RTT TLS1.3, qui permet d’envoyer immédiatement les données utiles.
[0187] Dans un ou plusieurs modes de réalisation, un dispositif configuré pour la mise en œuvre d’une fonction de traitement intermédiaire peut être configuré pour maintenir la table RCCB, afin de traiter le cas de figure dans lequel des adresses externes différentes sont utilisées par la fonction pour relayer une connexion donnée. Cette table est utilisée en particulier pour garder en mémoire l’adresse IP et le numéro de port externes utilisés par la fonction pour cette connexion.
[0188] La figure 5b illustre un exemple de structure de table RCCB maintenue par une fonction OFi située sur le chemin de transmission de données entre un premier terminal Tl et un deuxième terminal T2 entre lesquels est établie une connexion chiffrée. La table RCCB illustrée sur la figure 5b comprend les champs suivants :
[0189] « Upstream Connection Référencé » : Indique la référence de la connexion à relayer par la fonction OFi, le chemin des données transmises entre le premier terminal Tl et la fonction OFi étant désigné par chemin « Upstream ». Dans un ou plusieurs modes de réalisation, on pourra préférer utiliser les associations de sécurité TLS/DTLS à cet effet, plutôt que le quadruplet {adresse source, port source, adresse destination, port destination} , pour bénéficier d’une plus grande fiabilité.
[0190] « Downstream Connection Reference » : Indique la référence de la connexion telle que relayée par la fonction OFi, le chemin des données transmises entre la fonction OFi et le deuxième terminal T2 étant désigné par chemin « Downstream ». Dans un ou plusieurs modes de réalisation, ce champ pourra avoir la même structure et la même sémantique que le champ « Upstream Connection Reference » décrit ci-dessus.
[0191] « Token » : Ce champ correspond à « Shared Token » reçu dans une trame RELAY au titre d’une connexion « Upstream ». Ce champ est optionnel.
[0192] « Extemal IP Address » : Indique l’adresse IP utilisée par la fonction OFi comme adresse source pour relayer les paquets de la connexion.
[0193] « Extemal Port Number » : Indique le numéro de port utilisé par la fonction OFi comme numéro de port source pour relayer les paquets de la connexion.
[0194] « Next Hop IP Address » : Indique l’adresse IP utilisée par la fonction OFi comme adresse de destination pour relayer les paquets de la connexion. Ce champ est optionnel ; l’information peut être déduite en utilisant la référence de la connexion « Downstream ».
[0195] « Next Hop Port Number » : Indique le numéro de port utilisé par la fonction OFi comme adresse source pour relayer les paquets de la connexion. Ce champ est optionnel ; l’information peut être déduite en utilisant la référence de la connexion « Downstream ».
[0196] Dans un ou plusieurs modes de réalisation, si une connexion « Upstream » est associée à plusieurs connexions « Downstream », la politique de répartition de trafic entre ces différentes connexions est typiquement locale à la fonction OFi. [0197] De plus, dans un ou plusieurs modes de réalisation, une fonction OF sollicitée dans les deux sens d’une connexion QUIC (« Tl vers T2 » et « T2 vers Tl ») peut maintenir dans sa table RCCB des entrées qui correspondent à chaque direction.
[0198] Dans un ou plusieurs modes de réalisation, tout paquet destiné à une fonction OFi, mais qui ne contient pas de trame RELAY, peut être traité selon les consignes de la table RCCB maintenue par la fonction OFi. A réception d’un tel paquet, la fonction OFi peut consulter sa table RCCB pour récupérer le cas échéant la référence d’une connexion « Downstream ». Une fois le service OFi exécuté sur le paquet (par exemple, transcodage), le paquet peut être transmis en utilisant les informations renseignées dans la table RCCB (adresse source, numéro de port source, adresse destination, numéro de port destination). A noter que le service de la fonction OFI n’est pas exécuté si aucune entrée n’est trouvée dans la table RCCB.
[0199] Dans un ou plusieurs modes de réalisation, la trame GLUE peut n’être utilisée que pour un nombre prédéterminé de premiers paquets éligibles (par exemple, pour le premier paquet ou les trois premiers paquets) dans une nouvelle connexion secondaire, et peut être omise pour les autres paquets.
[0200] La figure 6a est un diagramme illustrant le procédé proposé selon un ou plusieurs modes de réalisation, du point de vue du terminal distant (deuxième terminal).
[0201] On considère des premier et deuxième terminaux, entre lesquels une première connexion chiffrée est établie (80) pour la transmission de données entre le premier terminal et le deuxième terminal.
[0202] Dans un ou plusieurs modes de réalisation, le procédé proposé peut comprendre, au deuxième terminal, la mémorisation (81), en association avec la première connexion, d’une fonction de traitement intermédiaire destinée à être appliquée entre le premier terminal et le deuxième terminal sur au moins une partie des données transmises entre le premier terminal et le deuxième terminal, d’un filtre caractérisant la au moins une partie des données éligibles, ainsi que d’une clé partagée avec le premier terminal.
[0203] Le deuxième terminal peut en outre recevoir (82) au moins un premier message en provenance de la fonction de traitement intermédiaire, le premier message transportant des données émises par le premier terminal. [0204] Le traitement de ce premier message reçu peut comprendre une vérification que les données transportées par le premier message correspondent au filtre mémorisé.
[0205] En cas de correspondance, le deuxième terminal peut accepter (83) l’établissement d’une deuxième connexion chiffrée avec la fonction de traitement intermédiaire et associer la deuxième connexion à la première connexion. De cette sorte, le deuxième terminal peut, sur réception de données via la deuxième connexion et correspondant au filtre, associer les données reçues à la première connexion.
[0206] Comme discuté ci-dessus, dans les modes de réalisation dans lesquels la première connexion entre les deux terminaux est établie selon le protocole QUIC, le premier terminal peut insérer une trame QUIC de type COCON tel que décrit ci-dessus, dans un message de contrôle ou un message de données de la première connexion (connexion principale) à destination du terminal distant, auquel cas le premier message reçu par le deuxième terminal peut être une trame COCON, par exemple selon le format illustré par la figure 4a.
[0207] Ainsi, dans un ou plusieurs modes de réalisation, à réception d’une trame COCON par le deuxième terminal (terminal distant), ce dernier peut mettre à jour ses tables de connexions QUIC pour sauvegarder une copie des informations contenues dans le message. En particulier, le terminal peut mettre à jour une table TRS pour garder en mémoire des données incluses dans le message COCON.
[0208] La figure 6b illustre un exemple de table TRS, dont la structure est similaire à celle décrite précédemment pour le premier terminal (concernant les offres faites par le premier terminal) et illustrée sur la figure 4b, hormis le champ « status » :
[0209] La table TRS illustrée à la figure 6b (pour la connexion principale « Primary Connection Ref »), contient les informations suivantes extraites du message COCON :
[0210] « OF ID » : un identifiant d’une fonction OF.
[0211] « Direction » : dans un ou plusieurs modes de réalisation, ce champ indique une première valeur indiquant une utilisation de la fonction identifiée par le champ OF ID unidirectionnelle à l’initiative du deuxième terminal, c’est-à-dire pour des données envoyées par le deuxième terminal, une deuxième valeur indiquant une utilisation de la fonction identifiée par le champ OF ID unidirectionnelle à l’initiative du premier terminal, c’est-à-dire pour des données envoyées par le premier terminal, ou une troisième valeur indiquant une utilisation de la fonction identifiée par le champ OF ID bidirectionnelle, c’est-à-dire pour des données envoyées par le premier terminal ou par le deuxième terminal. Par exemple, ce champ peut indiquer l’une des valeurs suivantes : 0 (Unidirectionnel à l’initiative du terminal), 1 (Unidirectionnel à l’initiative du terminal distant), 2 (bidirectionnel).
[0212] « Token » : Une clé de vérification qui doit être présentée au deuxième terminal (par une fonction OF) pour établir une nouvelle connexion secondaire.
[0213] Liste des « Stream IDs » : Un filtre qui liste des canaux dont les données peuvent être relayées par la fonction identifiée dans le champ OF ID. Dans un ou plusieurs modes de réalisation, une valeur prédéterminée (par exemple dénommée « Any ») peut être utilisée pour indiquer que la fonction peut être invoquée par tous les canaux d’une connexion.
[0214] Liste des « Connection IDs » : Un filtre qui liste des identifiants de connexion dont les données font l’objet d’un traitement par la fonction identifiée dans le champ OF ID. Dans un ou plusieurs modes de réalisation, une valeur prédéterminée (par exemple dénommée « Any ») peut être utilisée pour indiquer que la fonction peut être invoquée pour n’importe quel identifiant d’une connexion.
[0215] Dans un ou plusieurs modes de réalisation, le deuxième terminal peut être configuré pour ne retenir une fonction OF que pour une direction donnée. Par exemple, le terminal peut remplacer la valeur du bit « D » selon des politiques locales. Par exemple, en référence à la figure 4f, si Tl propose une fonction de transcodage OF1 pour un canal bidirectionnel, T2 peut décider d’utiliser une autre fonction de transcodage OF2 pour le même canal.
[0216] Un message d’acquittement de la trame COCON peut ensuite être envoyé au premier terminal.
[0217] Comme discuté ci-dessus, dans les modes de réalisation dans lesquels la première connexion entre les deux terminaux est établie selon le protocole QUIC, le dispositif ou l’équipement configuré pour la mise en œuvre de l’unique fonction ou, dans le cas où plusieurs fonctions sont invoquées pour un même paquet de données transmis entre les deux terminaux, de la dernière fonction à mettre en œuvre pour le paquet, peut insérer une trame QUIC de type GLUE tel que décrit ci-dessus, dans un message de contrôle ou un message de données de la deuxième connexion (connexion secondaire) à destination du deuxième terminal, auquel cas le premier message reçu par le deuxième terminal peut être une trame GLUE, telle que décrite ci-dessus.
[0218] En référence à la figure 6c, dans un ou plusieurs modes de réalisation, le deuxième terminal (T2) peut être configuré pour, à réception (90) d’un message contenant une trame GLUE(), extraire l’identifiant de la connexion, l’identifiant du canal, la clé « Shared Token » et l’identifiant de la fonction selon les modalités suivantes :
[0219] L’identifiant du canal et de connexion peuvent être extraits selon les modalités décrites dans la spécification QUIC.
[0220] L’identifiant « Shared Token » peut être extrait (91) de la trame GLUE. Par défaut, le deuxième terminal ignore (92) la trame GLUE reçue en cas d’échec d’extraction de l’identifiant « Shared Token ».
[0221] L’identifiant de la fonction peut être extrait en utilisant la trame GLUE (en utilisant le champ « mylD ») ou, en variante, en appliquant un algorithme de calcul de hash (par ex. SHA-256) de l’information "Pre-Shared Key (PSK) identity" utilisée par la fonction OF dans le message TLS « ClientKeyExchange ».
[0222] Après avoir extrait ces informations, le deuxième terminal peut être configuré pour consulter (94) la table TRS décrite ci-dessus maintenue par le deuxième terminal pour vérifier si les informations ainsi extraites correspondent à une entrée de la table TRS. Si une entrée a été trouvée (95), le deuxième terminal accepte (96) l’établissement de la nouvelle connexion collaborative TLS depuis la fonction OF. Un pointeur vers cette nouvelle connexion est alors ajouté à la table de connexions QUIC. Ainsi, les données reçues en utilisant une connexion secondaire (par exemple, OF-T2) sont associées à la connexion principale T1-T2. Par défaut, le deuxième terminal ignore (92) la trame GLUE reçue si aucune entrée n’est trouvée dans sa table TRS.
[0223] Dans un ou plusieurs modes de réalisation, le deuxième terminal peut être configuré pour n’appliquer cette procédure de contrôle que pour un nombre prédéterminé de premiers paquets (par ex. 3) faisant l’objet d’un traitement par la fonction OF. Dans ce cas, les paquets suivants pourront être traités selon les consignes de la table CCT, et la trame GLUE ne plus être utilisée. [0224] La figure 6d illustre un exemple de procédé de traitement d’un nouveau paquet reçu par le deuxième terminal selon un ou plusieurs modes de réalisation du procédé proposé.
[0225] Sur réception (97) d’un nouveau paquet, le terminal détermine (98) si le paquet reçu est ou non associé à une nouvelle connexion principale. Dans le cas où le paquet reçu est associé à une nouvelle connexion principale, il est traité (99) en considérant une nouvelle connexion principale tel que décrit précédemment. Dans le cas où le paquet reçu n’est pas associé à une nouvelle connexion principale, le terminal détermine (100) si le paquet reçu est ou non associé à une nouvelle connexion secondaire. Dans le cas où le paquet reçu est associé à une nouvelle connexion secondaire, il est traité (101) en considérant une nouvelle connexion secondaire tel que décrit précédemment. Dans le cas où le paquet reçu est associé avec une connexion secondaire existante (c’est-à-dire, une entrée correspondant à ce paquet a été trouvée dans la table CCT), le terminal le traite (102) en utilisant les consignes de ladite entrée de la table CCT, comme décrit ci-dessus.
[0226] Dans un ou plusieurs modes de réalisation, les paquets sont rejetés si aucune entrée n’est trouvée dans la table TRS (pour les N premiers paquets, N étant un entier prédéterminé) ou si aucune entrée n’est trouvée dans la table CCT (pour les autres paquets).
[0227] Différents exemples de cas de figure d’utilisation du procédé proposé selon un ou plusieurs modes de réalisation sont fournis ci-après, en référence aux figures 7a à 7f.
[0228] Les figures 7a à 7c montrent différents exemples de rejet d’une fonction OF, pour les communications, dans un réseau de communication, entre un premier terminal Tl et un deuxième terminal T2 (terminal distant) entre lesquels est établie une connexion QUIC.
[0229] La figure 7a illustre le cas où une fonction OF fait l’objet d’une tentative d’insertion dans une connexion (par exemple à des fins de vol de données), mais la connexion est rejetée par T2 car la clé présentée dans la trame COCON associée ne correspond à aucune entrée de la table TRS maintenue par T2.
[0230] La Figure 7b illustre le cas où une fonction OF fait l’objet d’une tentative d’insertion dans une connexion (par exemple à des fins de vol de données), mais la connexion est rejetée par T2 car l’identifiant du canal ne correspond pas à celui indiqué dans la table TRS maintenue par T2.
[0231] La Figure 7c illustre le cas où une fonction OF fait l’objet d’une tentative d’insertion dans une connexion (par exemple à des fins de vol de données), mais la connexion est rejetée par T2 car l’identifiant de fonction présenté ne correspond à aucune entrée de la table TRS maintenue par T2 pour Tl .
[0232] Les figures 7d à 7f montrent différents exemples de connexion collaborative réussie, pour les communications, dans un réseau de communication, entre un premier terminal Tl et un deuxième terminal T2 (terminal distant) entre lesquels est établie une connexion QUIC.
[0233] La Figure 7d illustre l’exemple d’une connexion collaborative réussie entre Tl et T2. Cette connexion implique une seule fonction OF1 telle que décrite dans la trame COCON envoyée par Tl à destination de T2 :
COCON(OFl, 485rFIjaKLkalBbjrCJghiD, stream_id=0x04579) (offre d’utilisation de la fonction OF1 pour les données émises sur le canal d’identifiant « 0x04579 », avec partage de la clé « 485rFIjaKLkalBbjrCJghiD » avec la fonction OF1). Les connexions sont relayées selon les consignes renseignées dans la table RCCB.
[0234] Sur réception de la trame COCON en provenance du premier terminal Tl, le deuxième terminal T2 instancie une entrée dans sa table TRS, comme décrit ci-dessus, et transmet éventuellement un acquittement d’acceptation de l’offre d’utiliser la fonction OF1 au premier terminal Tl. Le premier terminal Tl transmet à la fonction OF1 des données (DATA) sur lesquelles le service de la fonction OF1 doit être effectué ainsi qu’une trame RELAY(@T2, 485rFIjaKLkalBbjrCJghiD, ...) indiquant l’adresse de T2 et la clé partagée avec la fonction OF1. La fonction OF1 effectue sur les données reçues avec la trame RELAY le service correspondant à la fonction OF1 (par exemple, il transcode les données reçues), instancie une entrée dans sa table RCCB, et transmet les données traitées (DATA) au deuxième terminal ainsi qu’une trame GLUE(485rFIjaKLkalBbjrCJghiD, ...). Sur réception de la trame GLUE(485rHjaKLkalBbjrCJghiD, ...), le deuxième terminal T2 n’associe les deux connexions TLS qu’ après avoir vérifié que sa table TRS contenait bien une entrée correspondant à la fonction OF1 et à la clé reçue de OF1 (« 485rFIjaKLkalBbjrCJghiD »). Le deuxième terminal T2 instancie en outre une entrée dans sa table CCT, comme décrit ci-dessus. Il émet ensuite éventuellement une trame GLUE de confirmation d’association de connexions GLUE(Confirmed, OF1, 0x04579, ...) à destination du terminal Tl. Comme indiqué ci-dessus, la transmission des données suivantes entre le premier terminal et la fonction OF1 d’une part, puis entre la fonction OF1 et le deuxième terminal T2 d’autre part, peuvent ne pas utiliser de messages RELAY et/ou GLUE, respectivement. A réception des données par la fonction OF1, le service OF1 est mis en œuvre, puis les consignes de relais pour les données traitées sont obtenues en consultant la table RCCB. A réception des données traitées par le deuxième terminal T2, les données reçues sont associées à deux connexions collaboratives TLS sur la base de la table CCT. Si la fonction OF1 est éventuellement invoquée pour les deux directions de la connexion, un traitement similaire est effectué par OF1 pour les paquets reçus de T2 à destination de Tl.
[0235] La Figure 7e illustre un autre exemple de connexion collaborative réussie entre des premier et deuxième terminaux Tl et T2 et qui implique deux fonctions OF1 et OF2.
[0236] La connexion entre Tl et T2 implique deux fonctions OF1 et OF2 telles que décrites dans la trame COCON envoyée par Tl à destination de T2 :
COCON(OF2, CJghiD, stream_id=0x04579) (offre d’utilisation de la fonction OF2 pour les données émises sur le canal d’identifiant « 0x04579 », avec partage de la clé « CJghiD » avec la fonction OF2). Les connexions sont relayées selon les consignes renseignées dans les tables RCCB respectives maintenues par les dispositifs mettant respectivement en œuvre les fonctions OF1 et OF2.
[0237] Sur réception de la trame COCON en provenance du premier terminal Tl, le deuxième terminal T2 instancie une entrée dans sa table TRS, comme décrit ci-dessus, et transmet éventuellement un acquittement d’acceptation de l’offre d’utiliser la fonction OF2 au premier terminal Tl. Le premier terminal Tl transmet à un dispositif de mise en œuvre de la fonction OF1 des données (DATA) sur lesquelles le service de la fonction OF1 doit être effectué ainsi qu’une trame RELAY({@OF2,@T2}, CJghiD, ...) indiquant la clé partagée avec la fonction OF1. Le dispositif de mise en œuvre de la fonction OF1 effectue sur les données reçues avec la trame RELAY le service correspondant à la fonction OF1 (par exemple, il transcode les données reçues), instancie une entrée dans sa table RCCB, et transmet à un dispositif de mise en œuvre de la fonction OF2 les données traitées (DATA) ainsi qu’une trame RELAY(@T2, CJghiD, ...) indiquant la clé partagée avec la fonction OF2 (qui est, dans cet exemple, identique à la clé partagée avec la fonction OF1). Le dispositif de mise en œuvre de la fonction OF2 effectue sur les données reçues avec la trame RELAY le service correspondant à la fonction OF2, instancie une entrée dans sa table RCCB, et transmet les données traitées au deuxième terminal ainsi qu’une trame GLUE(CJghiD, ...). Sur réception de la trame GLUE(CJghiD, ...), le deuxième terminal T2 n’associe les deux connexions TLS qu’ après avoir vérifié que sa table TRS contenait bien une entrée correspondant à la fonction OF2 et à la clé reçue de OF2 (« CJghiD ») pour cette connexion. Le deuxième terminal T2 instancie en outre une entrée dans sa table CCT, comme décrit ci-dessus. Il émet ensuite éventuellement une trame GLUE de confirmation d’association de connexions à destination du terminal Tl (non représentée sur la figure). Comme indiqué ci-dessus, les transmissions suivantes de données entre le premier terminal et la fonction OF1 d’une part, entre les fonctions OF1 et OF2, puis entre la fonction OF2 et le deuxième terminal T2 d’autre part, peuvent ne pas utiliser de messages RELAY et/ou GLUE, respectivement. A réception de données par la fonction OF1 (respectivement OF2), le service OF1 (respectivement OF2) est mis en œuvre pour les données reçues, puis les consignes de relais pour les données traitées sont obtenues en consultant la table RCCB. A réception des données traitées par le deuxième terminal T2, les données reçues sont associées à deux connexions collaboratives TLS sur la base de la table CCT.
[0238] La Figure 7f illustre un autre exemple de connexion collaborative réussie entre Tl et T2 qui implique deux fonctions OF1 et OF2 : La fonction OF1 est impliquée pour les données du canal envoyées par Tl à T2, alors que les données du même canal émises par T2 vers Tl sont traitées par OF2. L’ordre des trames COCON est fourni à titre d’exemple.
[0239] Dans un ou plusieurs modes de réalisation, le terminal T2 peut informer Tl de l’ajout d’une fonction OF à une connexion. Pour ce faire, T2 envoie une trame GLUE(Confirmed, OF ID, List{stream_id}, ...) vers Tl. Tl peut utiliser cette trame pour détecter l’insertion a priori non-consentie d’une fonction OF. Il peut signaler à T2 le rejet de cette connexion secondaire en envoyant un message COCON(UPDATE), comme décrit ci-dessus.
[0240] La figure 8a illustre un exemple d’architecture d’un terminal pour la mise en œuvre du procédé proposé.
[0241] En référence à la figure 8a, le dispositif 100 comprend un contrôleur 101, couplé de manière opérationnelle à une interface de communication 102 et à une mémoire 103, qui pilote un module de gestion de communications selon un protocole QUIC 104.
[0242] L’interface de communication 102 comprend une ou plusieurs unités de communication, chacune configurée pour émettre et/ou recevoir des données selon un ou plusieurs protocoles de communication de données (par voie fdaire ou sans-fd), par exemple de type WLAN, Ethernet, LTE, LTE -A.
[0243] Le contrôleur 101 est configuré pour piloter le module de gestion de communications 104 et l’interface de communication 102 pour la mise en œuvre d’un ou de plusieurs modes de réalisation du procédé proposé.
[0244] Le module de gestion de communications 104 est configuré pour la mise en œuvre du procédé proposé par un terminal. En particulier, le module de gestion de communications 104 peut être configuré pour remplir les fonctions et accomplir les actes décrits dans la présente description pour la mise en œuvre du procédé proposé par un terminal (local et/ou distant).
[0245] Le dispositif 100 peut être un ordinateur, un réseau d’ordinateurs, un composant électronique, ou un autre appareil comportant un processeur couplé de manière opérationnelle à une mémoire, ainsi que, selon le mode de réalisation choisi, une unité de stockage de données, et d'autres éléments matériels associés comme une interface de réseau et un lecteur de support pour lire un support de stockage amovible et écrire sur un tel support (non représentés sur la figure). Le support de stockage amovible peut être, par exemple, un disque compact (CD), un disque vidéo/polyvalent numérique (DVD), un disque flash, une clé USB, une mémoire SSD, etc. En fonction du mode de réalisation, la mémoire, l’unité de stockage de données ou le support de stockage amovible contient des instructions qui, lorsqu'elles sont exécutées par le contrôleur 101, amènent ce contrôleur 101 à effectuer ou contrôler les parties module de gestion de communications 104 et interface de communication 102 des exemples de mise en œuvre du procédé proposé décrits dans la présente description. Le contrôleur 101 peut être un composant implémentant un processeur ou une unité de calcul pour la gestion de communications selon le procédé proposé et le contrôle des unités 102 et 104 du dispositif 100.
[0246] Le dispositif 100 peut être mis en œuvre sous forme logicielle, sous forme matérielle, comme un circuit intégré spécifique application (ASIC), ou sous forme d’une combinaison d'éléments matériels et logiciels, comme par exemple un programme logiciel destiné à être chargé et exécuté sur un composant de type FPGA (Field Programmable Gâte Array). De même, le module de gestion de communications 104 peut être mis en œuvre sous forme logicielle, sous forme matérielle, comme un ASIC, ou sous forme d’une combinaison d'éléments matériels et logiciels, comme par exemple un programme logiciel destiné à être chargé et exécuté sur un composant de type FPGA.
[0247] La figure 8b illustre un exemple d’architecture d’un dispositif configuré pour la mise en œuvre d’une ou plusieurs fonctions de traitement intermédiaires pour la mise en œuvre du procédé proposé.
[0248] En référence à la figure 8b, le dispositif 200 comprend un contrôleur 201, couplé de manière opérationnelle à une interface de communication 202 et à une mémoire 203, qui pilote un module de service de fonction 204.
[0249] L’interface de communication 202 comprend une ou plusieurs unités de communication, chacune configurée pour émettre et/ou recevoir des données selon un ou plusieurs protocoles de communication de données (par voie filaire ou sans-fil), par exemple de type WLAN, Ethernet, LTE, LTE -A.
[0250] Le contrôleur 201 est configuré pour piloter le module de service de fonction 204 et l’interface de communication 202 pour la mise en œuvre d’un ou de plusieurs modes de réalisation du procédé proposé.
[0251] Le module de service de fonction 204 est configuré pour la mise en œuvre du procédé proposé par un nœud mettant en œuvre une fonction. En particulier, le module de service de fonction 204 peut être configuré pour remplir les fonctions et accomplir les actes décrits dans la présente description pour la mise en œuvre du procédé proposé par un nœud mettant en œuvre une fonction.
[0252] Le dispositif 200 peut être un ordinateur, un réseau d’ordinateurs, un composant électronique, ou un autre appareil comportant un processeur couplé de manière opérationnelle à une mémoire, ainsi que, selon le mode de réalisation choisi, une unité de stockage de données, et d'autres éléments matériels associés comme une interface de réseau et un lecteur de support pour lire un support de stockage amovible et écrire sur un tel support (non représentés sur la figure). Le support de stockage amovible peut être, par exemple, un disque compact (CD), un disque vidéo/polyvalent numérique (DVD), un disque flash, une clé USB, une mémoire SSD, etc. En fonction du mode de réalisation, la mémoire, l’unité de stockage de données ou le support de stockage amovible contient des instructions qui, lorsqu'elles sont exécutées par le contrôleur 201, amènent ce contrôleur 201 à effectuer ou contrôler les parties module de service de fonction 204 et interface de communication 202 des exemples de mise en œuvre du procédé proposé décrits dans la présente description. Le contrôleur 201 peut être un composant implémentant un processeur ou une unité de calcul pour la gestion de communications selon le procédé proposé et le contrôle des unités 202 et 204 du dispositif 200.
[0253] Le dispositif 200 peut être mis en œuvre sous forme logicielle, sous forme matérielle, comme un circuit intégré spécifique application (ASIC), ou sous forme d'une combinaison d’éléments matériels et logiciels, comme par exemple un programme logiciel destiné à être chargé et exécuté sur un composant de type FPGA (Field Programmable Gâte Array). De même, le module de service de fonction 204 peut être mis en œuvre sous forme logicielle, sous forme matérielle, comme un ASIC, ou sous forme d'une combinaison d’éléments matériels et logiciels, comme par exemple un programme logiciel destiné à être chargé et exécuté sur un composant de type FPGA.
[0254] La mise en œuvre du procédé proposé selon les modes de réalisation décrits dans la présente description permet avantageusement : (1) de valoriser le réseau de l’opérateur par l’introduction de mécanismes optimisant l’usage des ressources mobilisées pour l’établissement et la maintenance de communications QUIC, (2) de promouvoir les mécanismes d’invocation de fonctions réseau avec consentement explicite, (3) aux communications QUIC de bénéficier d’un support de l’opérateur réseau sous la forme d’une gestion optimisée des ressources mobilisées par ces communications afin d’améliorer le niveau de qualité associé à ces communications et tel que perçu par les utilisateurs, (4) de simplifier l’utilisation des clients QUIC grâce à une coordination/collaboration pragmatique avec le réseau des opérateurs, (5) d’introduire plus de flexibilité dans F invocation et le retrait de fonctions réseau sans induire de délais supplémentaires pour Féchange des données. Le niveau de sécurité et de robustesse associé à chaque communication QUIC est également maintenu, sinon renforcé par les moyens dont dispose l’opérateur, (6) de promouvoir de nouvelles pratiques telle que Finvocation à la demande des fonctions réseau, (7) de permettre Finvocation sélective de fonction réseau par canal ("stream").
Application industrielle
[0255] En fonction du mode de réalisation choisi, certains actes, actions, évènements ou fonctions de chacune des méthodes décrites dans le présent document peuvent être effectués ou se produire selon un ordre différent de celui dans lequel ils ont été décrits, ou peuvent être ajoutés, fusionnés ou bien ne pas être effectués ou ne pas se produire, selon le cas. En outre, dans certains modes de réalisation, certains actes, actions ou évènements sont effectués ou se produisent concurremment et non pas successivement.
[0256] Bien que décrits à travers un certain nombre d’exemples de réalisation détaillés, le procédé de pilotage proposé et le dispositif pour la mise en œuvre d’un mode de réalisation du procédé comprennent différentes variantes, modifications et perfectionnements qui apparaîtront de façon évidente à l’homme de l’art, étant entendu que ces différentes variantes, modifications et perfectionnements font partie de la portée de l’invention, telle que définie par les revendications qui suivent. De plus, différents aspects et caractéristiques décrits ci-dessus peuvent être mis en œuvre ensemble, ou séparément, ou bien substitués les uns aux autres, et l’ensemble des différentes combinaisons et sous-combinaisons des aspects et caractéristiques font partie de la portée de l’invention. En outre, il se peut que certains systèmes et dispositifs décrits ci-dessus n’incorporent pas la totalité des modules et fonctions décrits pour les modes de réalisation préférés.

Claims

Revendications
[Revendication 1] Procédé de communication dans un réseau, entre un premier terminal et un deuxième terminal entre lesquels est établie une première connexion chiffrée pour transmettre des données, le procédé comprenant au premier terminal :
mémoriser, en association avec ladite première connexion, au moins une deuxième connexion entre le premier terminal et le deuxième terminal via au moins une fonction de traitement intermédiaire destinée à être appliquée sur au moins une partie desdites données dites éligibles à la deuxième connexion, et un filtre caractérisant lesdites données éligibles à la deuxième connexion, ladite deuxième connexion étant chiffrée entre le premier terminal et ladite fonction de traitement intermédiaire,
envoyer, via ladite deuxième connexion, au moins un premier message destiné à ladite fonction intermédiaire et transportant des données pour le deuxième terminal correspondant audit filtre, le premier message comprenant une information selon laquelle lesdites données sont à destination du deuxième terminal.
[Revendication 2] Procédé selon la revendication 1 , comprenant envoyer via la première connexion des données à destination du deuxième terminal, données qui ne correspondent pas audit filtre.
[Revendication 3] Procédé selon la revendication 1 ou 2, comprenant en outre sur réception de données via ladite deuxième connexion, associer lesdites données à ladite première connexion si les données correspondent audit filtre.
[Revendication 4] Procédé selon l’une quelconque des revendications précédentes dans lequel ledit premier message comprend en outre une clé destinée à être présentée par la fonction intermédiaire au deuxième terminal, et partagée entre le premier terminal et le deuxième terminal.
[Revendication 5] Procédé selon l’une quelconque des revendications précédentes comprenant informer le deuxième terminal, dans au moins un message émis via ladite première connexion à destination du deuxième terminal, de l’utilisation de ladite fonction de traitement intermédiaire pour ladite au moins une partie desdites données.
[Revendication 6] Procédé selon la revendication 5 dans lequel ledit au moins un message informant le deuxième terminal de G utilisation de ladite fonction de traitement intermédiaire comprend au moins un élément parmi : - un identifiant de ladite fonction de traitement intermédiaire ;
- une clé à présenter par la fonction intermédiaire au deuxième terminal ;
- ledit filtre caractérisant les données éligibles à ladite deuxième connexion ;
- au moins un identifiant de connexion éligible à ladite deuxième connexion ; et
- une information de direction de transmission des données via la deuxième connexion à laquelle ladite fonction de traitement intermédiaire est appliquée.
[Revendication 7] Procédé selon la revendication 5 ou 6, dans lequel l’utilisation par le premier terminal de ladite deuxième connexion pour envoyer des données au deuxième terminal est conditionnée par la réception par le premier terminal d’un acquittement du deuxième terminal de l’utilisation de ladite fonction de traitement intermédiaire.
[Revendication 8] Procédé selon l’une quelconque des revendications précédentes dans lequel sur la deuxième connexion, une pluralité de fonctions de traitement intermédiaires peuvent être appliquées sur les données éligibles à la deuxième connexion dans un ordre déterminé et :
- ledit au moins un message transportant des données pour le deuxième terminal est destiné à la première fonction de traitement intermédiaire devant être appliquée auxdites données éligibles à la deuxième connexion,
- ledit premier message envoyé comprend en outre une première liste ordonnée selon ledit ordre déterminé identifiant les fonctions de ladite pluralité de fonctions de traitement intermédiaires distinctes de la première fonction devant être appliquées sur lesdites données éligibles.
[Revendication 9] Procédé selon la revendication 8 dans lequel ledit premier message envoyé comprend en outre une deuxième liste ordonnée selon ledit ordre déterminé de clés destinées à être présentées par chacune des fonctions de traitement intermédiaires identifiée dans la première liste à la fonction de traitement intermédiaire suivante dans ladite première liste ou, pour la dernière fonction de traitement intermédiaire de la première liste au deuxième terminal, la clé destinée à être présentée au deuxième terminal étant partagée entre le premier terminal et le deuxième terminal.
[Revendication 10] Procédé selon l’une quelconque des revendications précédentes comprenant informer le deuxième terminal via la première connexion d’une modification affectant G utilisation de ladite fonction de traitement intermédiaire.
[Revendication 11] Procédé selon l’une quelconque des revendications précédentes dans lequel :
- ladite première connexion est établie entre le premier terminal et le deuxième terminal selon le protocole QUIC ;
- au moins une dite deuxième connexion est établie selon le protocole TLS entre le premier terminal et le deuxième terminal via au moins une dite fonction intermédiaire apte à déchiffrer les données échangées via ladite deuxième connexion.
[Revendication 12] Procédé de communication dans un réseau, entre un premier terminal et un deuxième terminal entre lesquels est établie une première connexion chiffrée pour transmettre des données, le procédé comprenant au deuxième terminal :
- mémoriser, en association avec ladite première connexion, une fonction de traitement intermédiaire destinée à être appliquée entre le premier terminal et le deuxième terminal sur au moins une partie desdites données, un filtre caractérisant ladite au moins une partie des données et une clé partagée avec le premier terminal ;
- recevoir au moins un premier message en provenance de ladite fonction intermédiaire transportant des données émises par le premier terminal ;
- vérifier si lesdites données correspondent au filtre mémorisé ; et
- en cas de correspondance :
accepter l’établissement d’une deuxième connexion chiffrée avec la fonction intermédiaire et associer ladite deuxième connexion à la première connexion ; et
sur réception de données via ladite deuxième connexion correspondant audit filtre, associer lesdites données à la première connexion.
[Revendication 13] Procédé de communication selon la revendication 12, dans lequel ledit premier message comprend en outre une clé présentée par la fonction de traitement intermédiaire au deuxième terminal, l’établissement de la deuxième connexion chiffrée étant accepté si ladite clé reçue correspond à une clé partagée avec le premier terminal.
[Revendication 14] Procédé de communication selon la revendication 12 ou 13, comprenant envoyer des données vers le premier terminal via ladite deuxième connexion correspondant audit filtre dans un message destiné à la fonction intermédiaire.
[Revendication 15] Procédé de traitement de données transmises dans un réseau entre un premier terminal et un deuxième terminal entre lesquels est établie une première connexion chiffrée, le procédé comprenant, pour un premier dispositif configuré pour mettre en œuvre une première fonction de traitement intermédiaire de données transmises entre le premier terminal et le deuxième terminal sur une deuxième connexion via ledit premier dispositif :
- recevoir d’un premier dispositif du réseau au moins un premier message destiné au premier dispositif, transportant des données émises par le premier terminal à destination du deuxième terminal, ledit premier dispositif du réseau étant le premier terminal ou un deuxième dispositif configuré pour mettre en œuvre une deuxième fonction de traitement intermédiaire desdites données, la deuxième connexion étant chiffrée entre le premier dispositif et le premier dispositif, ledit premier message comprenant :
une première liste ordonnée identifiant au moins un deuxième dispositif du réseau à emprunter par ledit au moins un message pour être acheminé jusqu’au deuxième terminal, ledit au moins un deuxième dispositif étant le deuxième terminal ou au moins un troisième dispositif configuré pour mettre en œuvre une troisième fonction de traitement intermédiaire desdites données ; et
une deuxième liste ordonnée comprenant au moins une clé destinée à être présentée par chaque dispositif de la première liste au dispositif suivant dans ladite première liste, la clé destinée à être présentée au deuxième terminal étant partagée entre le premier terminal et le deuxième terminal ;
- appliquer la première fonction de traitement intermédiaire auxdites données transportées dans ledit au moins un premier message ;
- mettre à jour la première liste et la deuxième liste ; et
- envoyer à destination du dispositif suivant identifié dans la première liste, ledit au moins un premier message intégrant la mise à jour des première et deuxième listes, avec les données traitées par la première fonction de traitement intermédiaire et la clé extraite de la deuxième liste destinée à être présentée au dispositif suivant, la deuxième connexion étant chiffrée entre le premier dispositif et le dispositif suivant.
[Revendication 16] Procédé de traitement selon la revendication 15 comprenant :
- mémoriser pour la deuxième connexion :
une adresse IP source et un numéro de port source utilisés par le premier dispositif intermédiaire pour relayer lesdites données dudit au moins un premier message ; et une adresse IP destination et un numéro de port destination correspondant au dispositif suivant identifié dans la première liste vers lequel lesdites données dudit au moins un premier message sont transmises ; - recevoir du premier dispositif au moins un deuxième message destiné au premier dispositif intermédiaire, transportant des données émises par le premier terminal vers le deuxième terminal, dans lequel la première liste est absente ;
- appliquer la première fonction de traitement intermédiaire auxdites données transportées dans ledit au moins un deuxième message ;
- envoyer à destination de l’adresse IP destination et du port destination mémorisés, ledit au moins un deuxième message avec les données traitées par la première fonction de traitement intermédiaire.
[Revendication 17] Dispositif de communication de données, comprenant un processeur et une mémoire couplée de manière opérationnelle au processeur, dans lequel le processeur est configuré pour la mise en œuvre d’un procédé selon l’une quelconque des revendications 1 à 16.
[Revendication 18] Système de communication de données, comprenant un premier terminal configuré pour la mise en œuvre d’un procédé selon l’une quelconque des revendications 1 à 11, un deuxième terminal configuré pour la mise en œuvre d’un procédé selon l’une quelconque des revendications 12 à 14, et un dispositif configuré pour la mise en œuvre d’un procédé selon l’une quelconque des revendications 15 à 16.
[Revendication 19] Programme d’ordinateur, chargeable dans une mémoire associée à un processeur, et comprenant des portions de code pour la mise en œuvre des étapes d’un procédé selon l’une quelconque des revendications 1 à 16 lors de l’exécution dudit programme par le processeur.
EP20747451.1A 2019-06-28 2020-06-24 Procede de gestion d'une communication entre terminaux dans un reseau de communication, et dispositifs et systeme pour la mise en oeuvre du procede Pending EP3991392A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR1907115A FR3096532A1 (fr) 2019-06-28 2019-06-28 Procédé de gestion d’une communication entre terminaux dans un réseau de communication, et dispositifs et système pour la mise en œuvre du procédé
PCT/FR2020/051102 WO2020260825A1 (fr) 2019-06-28 2020-06-24 Procede de gestion d'une communication entre terminaux dans un reseau de communication, et dispositifs et systeme pour la mise en oeuvre du procede

Publications (1)

Publication Number Publication Date
EP3991392A1 true EP3991392A1 (fr) 2022-05-04

Family

ID=68733168

Family Applications (1)

Application Number Title Priority Date Filing Date
EP20747451.1A Pending EP3991392A1 (fr) 2019-06-28 2020-06-24 Procede de gestion d'une communication entre terminaux dans un reseau de communication, et dispositifs et systeme pour la mise en oeuvre du procede

Country Status (4)

Country Link
US (1) US20220272079A1 (fr)
EP (1) EP3991392A1 (fr)
FR (1) FR3096532A1 (fr)
WO (1) WO2020260825A1 (fr)

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN113258679B (zh) * 2021-06-08 2022-11-11 南方电网数字电网研究院有限公司 基于服务器实例缩容的电网监控系统通道分配方法
WO2024208092A1 (fr) * 2023-04-06 2024-10-10 华为技术有限公司 Procédé de transmission de données et appareil de communication

Family Cites Families (16)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20030101353A1 (en) * 2001-10-31 2003-05-29 Tarquini Richard Paul Method, computer-readable medium, and node for detecting exploits based on an inbound signature of the exploit and an outbound signature in response thereto
ATE426283T1 (de) * 2005-12-15 2009-04-15 Nokia Corp Verfahren, apparat und computerprogrammprodukt zur beibehaltung von abbildungszuordnungen
CN101207613B (zh) * 2006-12-21 2012-01-04 松下电器产业株式会社 跨网域信息通信的认证方法、系统及其装置
US8990563B2 (en) * 2010-09-15 2015-03-24 Telefonaktiebolaget L M Ericsson (Publ) Sending protected data in a communication network
EP2434715A1 (fr) * 2010-09-24 2012-03-28 Gemalto SA Procédé pour établir un canal de communication sécurisé
US9130742B2 (en) * 2012-03-30 2015-09-08 California Institute Of Technology Key agreement in wireless networks with active adversaries
EP2959707B1 (fr) * 2013-02-22 2020-08-26 Adaptive Mobile Security Limited Procédé et système de sécurité réseau
US10069649B2 (en) * 2013-11-06 2018-09-04 Citrix Systems, Inc. Systems and methods for performing service tag switching in an application delivery controller
US9548963B2 (en) * 2014-04-01 2017-01-17 At&T Intellectual Property I, L.P. Method and system to enable a virtual private network client
US9930013B2 (en) * 2014-11-14 2018-03-27 Cisco Technology, Inc. Control of out-of-band multipath connections
WO2017167392A1 (fr) * 2016-04-01 2017-10-05 Nokia Solutions And Networks Oy Gestion d'expérience dynamique dans les communications
WO2018076183A1 (fr) * 2016-10-25 2018-05-03 华为技术有限公司 Procédé, appareil, et système de transmission de données
US11599890B1 (en) * 2016-12-22 2023-03-07 Wells Fargo Bank, N.A. Holistic fraud cocoon
US10469453B2 (en) * 2017-02-10 2019-11-05 Juniper Networks, Inc. Granular offloading of a proxied secure session
US10958425B2 (en) * 2018-05-17 2021-03-23 lOT AND M2M TECHNOLOGIES, LLC Hosted dynamic provisioning protocol with servers and a networked responder
US10938838B2 (en) * 2018-08-31 2021-03-02 Sophos Limited Computer augmented threat evaluation

Also Published As

Publication number Publication date
FR3096532A1 (fr) 2020-11-27
WO2020260825A1 (fr) 2020-12-30
US20220272079A1 (en) 2022-08-25

Similar Documents

Publication Publication Date Title
FR3053197A1 (fr) Procede de communication udp via des chemins multiples entre deux terminaux
WO2019002754A1 (fr) Procédé de communication quic via des chemins multiples
FR2923969A1 (fr) Procede de gestion de trames dans un reseau global de communication, produit programme d'ordinateur, moyen de stockage et tete de tunnel correspondants
CN105786952B (zh) 可自动配置的传输堆栈
FR3096533A1 (fr) Procédé de gestion d’une communication entre terminaux dans un réseau de communication, et dispositifs pour la mise en œuvre du procédé
EP3991392A1 (fr) Procede de gestion d'une communication entre terminaux dans un reseau de communication, et dispositifs et systeme pour la mise en oeuvre du procede
EP3695571B1 (fr) Dispositif et procédé de transmission de données
EP3216189B1 (fr) Délégation d'intermédiation sur un échange de données chiffrées
EP4162658A1 (fr) Procede de discrimination d'un message entre un terminal et un serveur de donnees
FR2909241A1 (fr) Procedes et dispositifs de gestion dynamique des erreurs de transmission par des points d'interconnexion de reseaux.
EP2847939A1 (fr) Systeme de transmission de donnees
EP4449678A1 (fr) Mécanismes de communication avec un service accessible via un réseau de télécommunication prenant en compte la mobilité des services, des utilisateurs et des équipements
EP1432210A1 (fr) Dispositif de contrôle de traitements associés a des flux au sein d'un reseau de communications
US12425859B2 (en) Enhancing cybersecurity protection through diversified transport paths
EP3811578A1 (fr) Procédé de découverte de fonctions intermédiaires et de sélection d'un chemin entre deux équipements de communication
EP4162663B1 (fr) Procédé de capture d'un paquet d'une session chiffrée
EP2446608B1 (fr) Technique de contrôle d'accès par une entité cliente à un service
FR3137238A1 (fr) Procédé de suspension d’un jeton de certification permettant d’authentifier l’établissement d’une connexion entre deux équipements de communication, dispositifs et programmes d’ordinateur correspondants
FR3034604A1 (fr) Procede de protection d'un reseau de communication, dispositif, equipement de controle et programme d'ordinateur associes
EP4655915A1 (fr) Procédé de révocation d'un jeton de certification permettant d'authentifier l'établissement d'une connexion entre deux équipements de communication, dispositifs et programmes d'ordinateur correspondants
WO2025093520A1 (fr) Procédés et dispositifs pour la configuration et l'utilisation d'un réseau supportant des tranches réseau
WO2025003097A1 (fr) Procédés d'accès à un service, procédé de fourniture de services, procédé de contrôle, procédé de gestion, terminal, instance de service, contrôleur, nœud de bordure et programmes d'ordinateur correspondants
EP2119140A2 (fr) Procede d'acheminement par un routeur d'un paquet de donnees dans un reseau de communication par paquets supporte par un reseau de transport
FR2806236A1 (fr) Procede et dispositif de transfert d'un paquet de donnees dans un reseau de communication
FR2925251A1 (fr) Procedes de gestion de connexion dans un mode de dechargement d'une tete de tunnel, produit programme d'ordinateur, moyen de stockage et tetes de tunnel correspondants

Legal Events

Date Code Title Description
STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: UNKNOWN

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE INTERNATIONAL PUBLICATION HAS BEEN MADE

PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: REQUEST FOR EXAMINATION WAS MADE

17P Request for examination filed

Effective date: 20220118

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MK MT NL NO PL PT RO RS SE SI SK SM TR

DAV Request for validation of the european patent (deleted)
DAX Request for extension of the european patent (deleted)
RAP3 Party data changed (applicant data changed or rights of an application transferred)

Owner name: ORANGE

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: EXAMINATION IS IN PROGRESS

17Q First examination report despatched

Effective date: 20250814