EP3991391A1 - Procédé de gestion d'une communication entre terminaux dans un réseau de communication, et dispositifs pour la mise en oeuvre du procédé - Google Patents

Procédé de gestion d'une communication entre terminaux dans un réseau de communication, et dispositifs pour la mise en oeuvre du procédé

Info

Publication number
EP3991391A1
EP3991391A1 EP20747017.0A EP20747017A EP3991391A1 EP 3991391 A1 EP3991391 A1 EP 3991391A1 EP 20747017 A EP20747017 A EP 20747017A EP 3991391 A1 EP3991391 A1 EP 3991391A1
Authority
EP
European Patent Office
Prior art keywords
terminal
relay node
communication
service
relay
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
EP20747017.0A
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 EP3991391A1 publication Critical patent/EP3991391A1/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/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0884—Network architectures or network communication protocols for network security for authentication of entities by delegation of authentication, e.g. a proxy authenticates an entity to be authenticated on behalf of this entity vis-à-vis an authentication entity
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/02—Network architectures or network communication protocols for network security for separating internal from external traffic, e.g. firewalls
    • H04L63/0281—Proxies
    • 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/0853—Network architectures or network communication protocols for network security for authentication of entities using an additional device, e.g. smartcard, SIM or a different communication terminal
    • 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/51—Discovery or management thereof, e.g. service location protocol [SLP] or web services
    • 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
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/56—Provisioning of proxy services
    • H04L67/561—Adding application-functional data or data for application control, e.g. adding metadata
    • 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
    • H04L67/563—Data redirection of data network streams
    • 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/164—Adaptation or special uses of UDP protocol
    • 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
    • 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
    • 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

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 the QUIC protocol.
  • the QUIC protocol described in the Internet Engineering Task Force (IETL) draft specification entitled "QUIC: A UDP-Based Multiplexed and Secure Transport” is an example. It was originally specified to relieve the operating system of the constraints imposed by the transport layer support.
  • 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.
  • the use of UDP also makes it easier to accommodate the presence of firewalls and NAT (Network Address Translation) functions on the path supporting QUIC communication.
  • QUIC not only encrypts the payload data, but also the connection control information. QUIC information sent in the clear is kept to the strict minimum.
  • a QUIC packet comprises encrypted payload data (in English, “Encrypted Payload”, or “EP”) and unencrypted header data (in English, “Public Header”, or “PH”).
  • the header data is organized into three fields: a binary flags field (in English "Flags", or "F"), a connection identifier field (in English “Connection ID", or "CID”), and a packet index field (in English "Packet Number", or " PN ”).
  • a QUIC communication offers the possibility of multiplexing different channels (in English "streams") Each channel is identified by a unique channel identifier (in English, "stream ID") for the time that the QUIC communication lasts .
  • the least significant bits of the channel identifier indicate the nature of the channel.
  • the first least significant bit indicates the initiator of the channel (client or server), and the second least significant bit is used to distinguish one-way channels from two-way channels.
  • the QUIC protocol does not impose a limit on the maximum number of channels or the nature of these channels (unidirectional, bidirectional).
  • a channel can be established at the initiative of the client or the server. Participants in a QUIC communication can, however, limit the number of channels opened by the remote terminal as well as the volume of data exchanged, using control frames sent for this purpose.
  • the data exchanged for a channel is encapsulated in a frame called "STREAM".
  • a specific channel is dedicated to the encryption of communication establishment exchanges ("Handshake") and to the negotiation of QUIC options.
  • QUIC signaling integrates information that makes it possible to control congestion and recover lost packets, in a mode of operation comparable to that of TCP.
  • the QUIC protocol does not rely on transport addresses (source IP address, source port number, destination IP address, destination port number) but on the connection identifier CID.
  • the IETL QUIC draft specification defines two types of CIDs: Destination CID and Source CID.
  • the QUIC protocol only supports a connection migration mechanism which makes it possible to maintain a QUIC connection in progress in the event of a modification of one of the addresses (or port numbers) of the participants (including changes of addresses allocated by intermediate NAT functions if applicable). Receipt of a message for a current connection is an indication of connection migration.
  • a connection migration can consist of moving from one quadruplet ⁇ source address, source port, destination address, destination port] to another.
  • the terminals validate the new address using PATH_CHALLENGE and PATH_RESPONSE frames exchanged between the participants to validate a connection migration. Note that the IETF QUIC draft specification considers that only one path is used at a time for a single QUIC connection.
  • the QUIC protocol specification project does not allow the provision, to terminals wishing to establish a QUIC communication, of additional services managed by the communication network used by said terminals and provided by network elements intermediaries placed on the path taken by the QUIC communication.
  • the presence of such relay nodes can induce modifications to the resources used for the QUIC communication and in particular modifications to the addresses and / or port numbers used during the communication.
  • modifications can lead to instability of the QUIC communication.
  • only a connection migration mechanism is currently provided in the QUIC protocol in the event of a change of address (es), and this mechanism requires the remote terminal to check for each modification detected that it is is the other terminal engaged in the QUIC communication which is at the origin of this modification. This verification is done by means of requests sent by the remote terminal which, in the presence of relay node (s) on the path used by the communication, may be rejected or fail.
  • a method for managing a communication established according to the QUIC protocol between a first terminal and a second terminal connected via a communication network comprising, at the first terminal: discovering at least a relay node between the first terminal and the second terminal, said relay node being able to provide at least one service for said communication; and if the first terminal accepts said service, send to the second terminal, during an establishment phase or during said communication, an encrypted relay information message comprising data identifying said at least one relay node and a token intended to be supplied by said at least one relay node to the second terminal.
  • the proposed method advantageously introduces a scheme for discovering a relay node within a communication network located on the path of a communication between two terminals, and for discovering the services offered by this relay node.
  • the proposed scheme also allows the use of such a relay node by two terminals in communication, for example established according to the procedures of the QUIC protocol on the network.
  • the use of a relay node within the framework of a QUIC communication opens up the possibility for the terminals of the communication to benefit from services, possibly offered by the relay node and / or accessible to the terminals through the relay node, such as for example anti-virus services, detection of covered channels, packet inspection or DPI (Deep Packet Inspection), mitigation of denial of service attacks, etc.
  • DPI Deep Packet Inspection
  • the possibility of involving a relay node in a communication established according to the procedures of the QUIC protocol between two terminals also allows the network operator to better manage the communication, and in particular the network resources assigned to the communication.
  • discovering said at least one relay node comprises receiving a message originating from the relay node or originating from the second terminal and having passed through said at least one relay node, comprising an indication of said service provided by said relay node and an identifier of said relay node.
  • the proposed method further comprises: if the first terminal accepts the provision of said service by said relay node, sending a message to the relay node or to the second terminal and passing through said relay node, comprising an indication intended for said relay node of the acceptance of said service by the first terminal and a token generated by the first terminal.
  • the relay information message further comprises at least one element from the reachability information of the relay node allowing access to said relay node, at least one identifier of at least one communication between the first and the second terminal taking a path involving the relay node and a challenge generated by the first terminal.
  • the proposed method further comprises: checking a reliability of the relay node before accepting said service.
  • the aforementioned diagrams advantageously allow a QUIC terminal to control the services offered by a QUIC relay, and to negotiate the services to be applied for the communications associated with this terminal.
  • said service comprises access by the relay node to multiple paths to support said communication between the first terminal and the second terminal.
  • the provision of a traffic distribution service via multiple paths by a relay node of the network advantageously allows an operator of this network to better control the policies for the distribution of traffic via multiple paths in the network, such as policies as activated by a QUIC terminal may not be optimal for the operator.
  • said message further comprises an algorithm for distributing the traffic load between said multiple paths intended to be applied by the relay node.
  • the proposed method further comprises: during the establishment or during said communication between the first and the second terminal, indicating to the second terminal that the first terminal supports an extension of the protocol QUIC which allows the establishment of said communication according to the QUIC protocol on multiple paths, even if only one path is available locally at the first terminal.
  • a QUIC terminal has no visibility concerning the multiple paths available in the network. Thanks to the proposed method, a QUIC communication can benefit from the resources associated with multiple paths, even if these multiple paths are not visible to either the client or the server. This makes it possible to improve the use of resources in the network, but also to improve the quality of experience as perceived by the customer (thanks to the ability to aggregate the bandwidth likely to be used by a QUIC communication , for example).
  • a method for managing a communication established according to the QUIC protocol between a first terminal and a second terminal connected via a communication network comprising, at the second terminal, during an establishment phase or during said communication: receiving, from the first terminal, an encrypted relay information message comprising a token and data identifying at least one relay node between the first terminal and the second terminal capable of providing at least one service for said communication.
  • the proposed method further comprises: storing for said communication said token and a first quadruplet comprising an address and a source port number, and an address and a destination port number of the message. relay information; on detection, in a subsequent message of said communication from the first terminal, of a source address different from the source address of the first quadruplet: check with the relay node whether said subsequent message has passed through the relay node; and if necessary, memorize for communication, a second quadruple comprising the address and the source port number, and the address and the destination port number of the subsequent message.
  • the second quadruple is stored while retaining the first quadruple.
  • the proposed method further comprises: during the establishment or during said communication between the first and the second terminal, indicating to the first terminal that the second terminal supports an extension of the protocol QUIC which allows the establishment of communications according to the QUIC protocol over multiple paths, even if only one path is available locally at the second terminal.
  • the verification comprises: sending a verification request message to the relay node comprising the source address of the second quadruplet or a challenge; receiving a response message from the relay node including a token; checking the coincidence between said token received from the relay node and the stored token.
  • the proposed method further comprises: if said tokens coincide, the use of the second quadruplet by the second terminal for sending encrypted messages to the first terminal.
  • a method for managing a communication established according to the QUIC protocol between a first terminal and a second terminal, connected via a communication network the method being implemented by a relay node of the communication network located between the first and the second terminal and capable of providing at least one service for said communication, said method comprising: inserting in at least one message intended for the first terminal, originating from the second terminal and passing through said relay node data indicating support by said relay node of said service, said data comprising an identifier of the relay node.
  • said data is included in a UDP (User Datagram Protocol) option.
  • UDP User Datagram Protocol
  • said service comprises access by the relay node to multiple paths which make it possible to support said communication between the first terminal and the second terminal.
  • said data further comprises at least one of a service offering identifier, at least one relay node reachability information item allowing access to said relay node, and data descriptions of the service provided by the relay node.
  • the proposed method further comprises: receiving from the first terminal a message of said communication comprising an indication of an acceptance by the first terminal of the service provided by the relay node and a token generated by the first terminal; storing in an active communications table for the first terminal said token associated with said communication.
  • the proposed method further comprises: following an acceptance of the service provided by the relay node by the first terminal, modifying a source or destination address and / or a source or destination port number a message from the first terminal or the second terminal, intended for the second terminal or to the first terminal and passing through the relay node which is responsible for relaying said message to the second terminal.
  • This mechanism advantageously makes it possible to respond to the problem of modifications of addresses or of port numbers as allocated by a relay node, modifications which can lead to instability of the QUIC communication because the remote terminal must check each time.
  • source address modification that the QUIC terminal is at the origin of a modification.
  • the requests used for this purpose can be rejected (at the "rate-limit" policy checkbox by the source terminal) or fail because the terminal is not aware of the modifications made in the network.
  • 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 of the method proposed in the present description.
  • 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.
  • FIG. 1 illustrates an example of a communication system for the implementation of one or more embodiments.
  • FIG. 2a illustrates an example of implementation of the method proposed according to one or more embodiments.
  • FIG. 2b illustrates an example of encapsulating a relay service advertisement information option in a UDP packet according to one or more embodiments.
  • FIG. 2c illustrates an example of implementation of the method proposed according to one or more embodiments.
  • FIG. 2d illustrates an example of implementation of the method proposed according to one or more embodiments.
  • FIG. 2e illustrates an example of implementation of the method proposed according to one or more embodiments.
  • FIG. 2f illustrates an example of implementation of the method proposed according to one or more embodiments.
  • FIG. 2g illustrates an example of a NEW_CONNECTION_ID frame modified to associate a relay with a connection identifier according to one or more embodiments.
  • FIG. 3a [0051] [Fig. 3a] illustrates an example of implementation of the method proposed according to one or more embodiments.
  • FIG. 3b illustrates a QUIC relay information frame according to one or more embodiments.
  • FIG. 4a illustrates an example of the establishment of an initial path taken by a QUIC communication according to one or more embodiments.
  • FIG. 4b illustrates an example of establishment of an initial path and a secondary path taken by a QUIC communication according to one or more embodiments.
  • FIG. 5a illustrates an example of the architecture of a terminal according to one or more embodiments.
  • FIG. 5b illustrates an example of the architecture of a relay node according to one or more embodiments.
  • the present description refers to functions, units, modules and diagram illustrations of the methods and devices according to one or more embodiments.
  • Each of the functions, modules, units and diagrams described can be implemented in hardware, software (including on-board software (“ firmware ”), or“ middleware ”), microcode, or any combination of these.
  • functions, units, modules and / or diagram illustrations can be implemented by computer program instructions or software code, which can be stored or transmitted over a computer readable medium (such as for example a computer storage medium (USB keys, CD-ROM, DVD, memory card, etc.) or a communication medium), including a non-transitory medium, or a medium loaded in memory of a generic, specific computer, or of any other programmable data processing device or device for producing a machine, such that computer program instructions or software code executed on the computer or the programmable data processing device or device constitute means for implementing these functions.
  • the instructions can include code from 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 equipment, 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 equipment, 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”), wired type connections, wireless type connections, cellular type, or any combination of these different networks.
  • operably coupled refers to couplings, connections, assemblies, which can be direct or indirect, and include in particular connections between electronic equipment or between portions of such equipment which allow operations and functions as described in the present description. These can be physical or mechanical connections or couplings, or via one or more wired and / or wireless connection (s)
  • terminal is used in the present description to denote any entity such as a software entity capable of functioning as an end point of a communication established according to the terms of the QUIC protocol.
  • a terminal which implements the QUIC protocol can act as a QUIC client, QUIC server, or both.
  • Examples of terminals include, without limitation, intelligent terminals (in English, “smartphones”), personal computers (in English, “Personal Computer” or “PC”), tablets, Internet network servers, etc. .
  • 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.
  • QUIC protocol or abbreviated “QUIC” is meant any protocol, conforming to a version of the specification of the QUIC protocol or 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, the implementation of which by Google is sometimes referred to as“ gQUIC ”(Google QUIC), including existing versions of these specifications or draft specifications and their evolutions. More generally, QUIC denotes any transport protocol encapsulated on another transport protocol of UDP or UDP-lite type (Lightweight User Datagram Protocol) but whose primitives and payload are completely encrypted.
  • FIG. 1 illustrates an example of a communication system (20) in which one or more embodiments of the proposed methods and devices can be implemented.
  • the system (20) comprises a first terminal T1 (20a) in communication with a second terminal T2 (20b) via a first network (22) to which the first terminal is connected, a relay node (in English, "proxy” or “relay") PI (21) connected to the first network (22) as well as to a second network (23), and to the second network (23) to which the second terminal T2 (20b) is connected.
  • a relay node in English, "proxy” or “relay”
  • the first network (22) may be a local area network (LAN) in which the terminal T1 is present
  • the second network may be a wide area network (WAN) (comprising a wireless network WLAN, a cellular network (2G, 3G, 4G and / or 5G), an ADSL network, a fiber access network (FTTH / FTTC) or any combination of these), in which the terminal T2 is present.
  • the relay node can be implemented in an access gateway, for example of the CPE type (from English "Customer Premises Equipment") when the gateway is residential.
  • the first terminal T1 and the second terminal T2 can perform communications according to the QUIC protocol (or "QUIC communications" for the sake of simplification in the remainder of the description), that is, that is, establish a connection according to the modalities provided for by the QUIC protocol and exchange data using this connection.
  • a relay node PI can be located on the path of the QUIC messages (ie conforming to the QUIC protocol) exchanged during the QUIC communication between the first terminal T1 and the second terminal T2.
  • the proposed method comprises, at a first terminal for which a QUIC communication is established with a second terminal, the discovery of at least one relay node between the first terminal and the second terminal, the relay node being able to provide at least one service for communication between the first terminal and the second terminal.
  • Relay nodes can provide various services such as anti-virus services, covered channel detection, packet or DPI inspection, denial of service attack mitigation, etc.
  • the discovery of a relay node can comprise the reception of a message from the relay node, or from the second. terminal and having passed through the relay node, comprising an indication of the service provided by the relay and an identifier of the relay node.
  • FIGS. 2a to 2d Described below are diagrams for the discovery of a relay node (and the services it supports) by a terminal according to one or more embodiments, with reference to FIGS. 2a to 2d.
  • FIG. 2a illustrates an example of a communication system (30) comprising a first terminal T1 (30a) in communication according to the QUIC protocol with a second terminal T2 (30b) via a first network NI (32 ) to which the first terminal is connected, of a relay node P i (31) connected to the first network (32) as well as to a second network comprising a plurality of subnetworks (33al - 33ai) connected to the Internet network (33b ), and the second network to which the second terminal T2 (30b) is connected.
  • the first network (32) can be a local area network (LAN) in which the terminal T1 is present.
  • the relay node (31) can be implemented in an access gateway, for example of the CPE type.
  • the relay node (31) can be configured to provide a service comprising access by the relay node to multiple paths which allow communication between the first terminal and the second terminal to be supported.
  • the first terminal T1 (30a) initiates a QUIC communication to the second terminal T2 (30b) while indicating that it supports QUIC extensions via multiple paths.
  • the first terminal T1 sends this frame even if only one and the same path is available locally at the level of the first terminal T1 (for example a single network interface is activated on the terminal T1): indeed, multiple paths can be offered. by other elements of the network such as for example by the relay node (31) or may appear as the network evolves.
  • the second terminal T2 can then confirm the activation of the QUIC extensions via multiple paths by also responding with an MP_STATUS (Enabled) frame.
  • the messages of the QUIC communication between the first terminal T1 and the second terminal T2 can then be exchanged via several paths.
  • terminal T1 deactivates the QUIC extensions via multiple paths.
  • the quadruplet source address, source port number, destination address, destination port number
  • the terminals migrate the QUIC communication in accordance with the current specification of the QUIC protocol. .
  • the MP_STATUS frame can be used to convey other information about the support by the multipath terminals.
  • other values can be provided for the Status field such as for example an “Unsupported” value indicating that the QUIC extensions via multiple paths are not supported by the terminal or a “Disabled” value indicating that the QUIC extensions via multiple paths are disabled by the terminal.
  • the MP_STATUS frame can be sent on initialization of the QUIC communication with the terminal T2, but also more generally, at any time of the communication. Both terminal T1 and terminal T2 can be the source of the sending of this frame. Likewise, both terminals can at any time disable support for QUIC extensions via multiple paths using the MP_STATU S (Disabled) frame.
  • the first terminal T1 (30a) and the second terminal T2 (30b) exchange QUIC messages as part of a communication according to the QUIC protocol established between these two terminals.
  • FIG. 3a illustrates an example of a sequence of transmissions of QUIC messages, in which the first terminal T1 (30a) sends a first QUIC message M1 to the second terminal T2 (30b), the second terminal T2 (30b) sends a second QUIC M2 message to the first terminal T1 (30a), then the first terminal T1 (30a) sends a third message QUIC M3 to the second terminal T2 (30b).
  • the relay node Pl i (31) is configured to insert, in a message intended for the first terminal and coming from the second terminal and passing through the relay node, data indicating the medium by the relay node of the service, the data comprising an identifier of the relay node.
  • the relay node Pl i (31) placed on the communication path according to the QUIC protocol between the first terminal T1 (30a) and the second terminal T2 (30b) (in other words , capable of intercepting messages exchanged between the two terminals), transmits to the first terminal a message (PROXY_SERVICE_OFFER) of the communication according to the QUIC protocol which includes data indicating the support by the relay node Pl i (31) of a service relay QUIC, for example an indication of the service that the relay node can provide and an identifier of the relay node.
  • the PROXY_SERVICE_OFFER message allows the relay node Pl i (31) to indicate to the first terminal Tl (30a) that it can provide one or more relay services as part of the QUIC communication between the first terminal and the second terminal.
  • the data indicating the support by the relay node PI 1 (31) of the relay service QUIC is included in a UDP option.
  • a relay service advertisement information can be inserted by a relay in a new UDP option, for example called PROXY_SERVICE_OFFER, as illustrated in FIG. 2b.
  • Figure 2b shows the encapsulation of a relay service advertisement information option (PROXY_SERVICE_OFFER) in a UDP datagram.
  • the IP packet (35) shown in the figure includes an IP header (35a) and a UDP datagram including a UDP header (36a), QUIC data (36b), and UDP options (36c) including an option “PROXY_SERVICE_OFFER” (36c 1) and a second UDP option (36c2).
  • the use of a UDP option advantageously makes it possible to overcome the constraints imposed by the encryption of the data exchanged according to the QUIC protocol.
  • PROXY_SERVICE_OFFER option can advantageously be inserted at any time during the duration of the QUIC connection between the first terminal and the second terminal.
  • one or more PROXY_SERVICE_OFFER options can be present in the same message. These options can also be inserted by the same relay node or by several relay nodes.
  • the data indicating the support by the relay node can comprise, in addition to the identifier of the relay node, at least one of a service offering identifier, at least one information of reachability of the relay node (ie the data allowing access to the relay node such as an IP address, also referred to as “locators” in the following), and descriptive data of the service provided by the relay node.
  • the data indicating the support by the relay node P i (31) of the relay service QUIC can comprise one or more first locators of the relay node (Locator (s)), thus that possibly, depending on the embodiment, a service offer identifier (“Offer_ID”), an identifier of the relay node (“Relay_ID”), and / or service description data (“Service Description”) .
  • the relay service announcement information can be inserted into a PROXY_SERVICE_OFFER option comprising a field carrying an identifier of the relay node (“Relay_ID”) and possibly one or more among a field carrying a service offer identifier ( "Offer_ID”), a field carrying locators of the relay node (“Locator (s)”) and a field carrying service description data ("Service Description").
  • Relay_ID a field carrying an identifier of the relay node
  • Offer_ID a field carrying locators of the relay node
  • Service Description a field carrying service description data
  • the PROXY_SERVICE_OFFER option can be structured according to a TLV format (Type, Length, Value).
  • the "Value” field can include at least one IP address, used to reach the relay node.
  • the “Value” field can comprise in one embodiment the following elements:
  • a first field (“Relay_ID”), carrying an identifier to identify the relay node which inserted the option. This information is useful if there are several relays in the same path. This identifier can also be used for identification purposes. In this case, the identifier is generated according to a formalism known to the terminals. The SHA-256 algorithm can for example be used to generate a hash based on the public security keys of a relay.
  • a second field (“Offer_ID”), carrying an identifier of a relay service offer. This identifier can advantageously be used to correlate the messages sent by a relay node and the responses received from a terminal, as described in more detail below. In doing so, the relay node controls the terminals to which it can offer its service. This identifier will preferably be generated in a random manner.
  • a third field carrying one or more locators to reach the relay node
  • a locator can for example be, depending on the embodiment, an IPv4 address, an IPv6 address or an IP address and a port number.
  • a fourth field carrying the description of the services offered by the relay.
  • this field indicates a list comprising one or more traffic load distribution algorithms supported by the relay node, and / or any information characteristic of the relay service.
  • This fourth field thus makes it possible to invite the first terminal to choose a service from the list.
  • the relay node can be configured to choose a default service if no choice is returned for the QUIC connection by the first terminal.
  • a check of the integrity of the content of the PROXY_SERVICE_OFFER option can be performed by the first terminal in accordance with the QUIC protocol used, for example using the "UDP checksum” or any other mechanism for checking the integrity of the device.
  • adapted content such as the definition of an "HMAC” field which carries the digest of the content of the PROXY_SERVICE_OFFER option (ie the application of a "keyed Hashed Message Authentication Code" (HMAC) function) .
  • HMAC Hashed Message Authentication Code
  • the descriptive data of the service (s) provided by the relay node can be incorporated by the relay node in a message of the communication established according to the received QUIC protocol, in from the second terminal, and to the first terminal.
  • the relay node Pl i (31) can insert into the message M2 coming from the second terminal (30b) and intended for the first terminal (30a) a relay support offer (service offer relay), in the form of a PROXY_SERVICE_OFFER message.
  • the message M2a received by the first terminal Tl (30a) comprises data (PROXY_SERVICE_OFFER) inserted by the relay node Pl i (31) and indicating the support by this relay node of a relay service.
  • the use of a message transmitted by a remote terminal (the second terminal T2) to a local terminal (the first terminal Tl) at the relay node Pl i to insert therein relay service offer data advantageously makes it possible to limit the signaling associated with the transmission of relay service offering data.
  • the relay node takes advantage of a QUIC message transmitted to the terminal T1 to send it service offer data.
  • the first terminal Tl (30a) can be configured to, following receipt of data indicating the medium by the relay node Pl i (31) of a relay service, to respond to the relay node Pl i (31) indicating that it accepts or refuses, as the case may be, to use the relay service (s) offered by the relay node Pl i (31).
  • the first terminal Tl (30a) refuses to use the relay service offered by the relay node Pl i (31), it can transmit to the relay node a QUIC message comprising data (for example a message "PROXY_SERVICE_DISCARD") indicating its refusal to use the relay service.
  • the relay node may receive, from the first terminal, a QUIC message including data indicating a refusal to use the relay service.
  • the data indicating its refusal to use the relay service may include the identifier of the relay node and / or the service offer identifier that the first terminal T1 (30a) will have received in data indicating the support of a relay service.
  • the first terminal Tl (30a) accepts to use the relay service offered by the relay node Pl i (31), it can send a message to the relay node Pl i (31), or to the second terminal and passing through the relay node Pl i (31), comprising an indication intended for the relay node Pl i (31) of the acceptance of the service by the first terminal Tl (30a), and a token generated by the first terminal T1 (30a).
  • the first terminal T1 (30a) in the case where the first terminal T1 (30a) accepts to use the relay service offered by the relay node PI 1 (31), it can transmit to the relay node a QUIC message including data indicating its acceptance to use the relay service.
  • the relay node can receive, from the first terminal, a QUIC message comprising data indicating an acceptance to use the relay service.
  • the relay information message may include at least one element of the reachability information of the relay node allowing access to the relay node, an identifier of a communication between the first and the second terminal taking a path involving the relay node, and a challenge generated by the first terminal.
  • the data indicating its acceptance of using the relay service may include the identifier of the relay node and a token generated for example randomly by the first terminal.
  • the data indicating its acceptance to use the relay service may further include the service offer identifier and / or all or part of the service description data that the first terminal T1 ( 30a) will have received in the data indicating the support of a relay service, as well as a challenge (or “Challenge”) generated, for example randomly, by the first terminal.
  • the relay node can be configured to receive, from the first terminal, a message of the communication between the first terminal and the second terminal comprising an indication of an acceptance by the first terminal of the service provided by the relay node and a token generated by the first terminal, then storing, in an active communications table for the first terminal, the received token, in association with the communication.
  • the relay node can also be configured to, following acceptance of the service provided by the relay node by the first terminal, modify a source or destination address and / or a port number. source or destination of a message coming from the first terminal or from the second terminal, intended for the second terminal or the first terminal, respectively, and passing through the relay node which is responsible for relaying said message to the second terminal.
  • the first terminal in the case where the first terminal refuses to use the relay service offered by the relay node, it can insert in a QUIC message sent to the second terminal data indicating a refusal of use the service of relay.
  • the relay node will receive, coming from the first terminal, a QUIC message intended for the second terminal which includes data (for example “PROXY_SERVICE_DISCARD”) indicating a refusal by the first terminal to use the relay service.
  • the first terminal T1 (30a) in the case where the first terminal T1 (30a) accepts to use the relay service offered by the relay node PI 1 (31), it can insert in a message QUIC (M3) sent to the second terminal T2 (30b) data (eg "PROXY_SERVICE_ACCEPT") indicating an acceptance to use the relay service.
  • M3 message QUIC
  • the relay node will receive, from the first terminal, a QUIC message to the second terminal comprising data (for example "PROXY_SERVICE_ACCEPT") indicating an acceptance of the first terminal to use the relay service.
  • relay service advantageously makes it possible to limit the signaling associated with the transmission of an explicit response to the relay service offer.
  • the local terminal T1 in fact takes advantage of a QUIC message transmitted to the remote terminal T2 to transmit to the relay node Pl i data for accepting or refusing the relay service.
  • the first terminal can be configured to, during the establishment of the communication between the first and the second terminal or at any other time during the communication, indicate to the second terminal that the first terminal supports an extension of the QUIC protocol which allows the establishment of the communication according to the QUIC protocol on multiple paths, even if only one path is available locally at the level of the first terminal.
  • the relay node can receive, from the first terminal, a message (M3a) from the communication established according to the QUIC protocol to the second terminal, comprising data (for example "PROXY_SERVICE_ACCEPT ") Indicating that the first terminal accepts the relay service.
  • the relay node can modify (M3a -> M3) the message of the communication established according to the QUIC protocol in order to remove the data indicating that the first terminal accepts the relay service, then transmit the modified message (M3) to the second terminal.
  • the relay node may further be configured to transmit data indicating the medium by the relay node of a relay service to the second terminal.
  • the relay node can be configured to determine that the first terminal is not interested in the relay service, in the event that no response to the message announcing the bearer by the relay node d 'a relay service is only received from the first terminal (implicit refusal), or if a message refusing to use the relay service has been received from the first terminal (explicit refusal).
  • the relay service offer message for example, "PROXY_SERVICE_OFFER Can include data indicating support by the relay node of a QUIC relay service via multiple paths.
  • the service offered by the relay node can include access by the relay node to multiple paths to support communication between the first terminal and the second terminal.
  • the relay node can receive, from the first terminal, a message from the communication established according to the QUIC protocol to the second terminal, comprising data indicating that the first terminal accepts use by the relay node. multiple paths that can be taken by the data exchanged as part of the communication established according to the QUIC protocol with the second terminal.
  • the relay node can further modify the QUIC message to delete therein data indicating that the first terminal accepts G use by the multiple path relay node for communication established according to the QUIC protocol with the second terminal, then transmit the modified message to the second terminal.
  • the relay node can be configured to include data indicating a relay service bearer (e.g. “PROXY_SERVICE_OFFER”) in a plurality of messages, or even in all the messages of a QUIC communication to a terminal (Tl).
  • a relay service bearer e.g. “PROXY_SERVICE_OFFER”
  • the same relay can be configured to include data indicating a relay service medium (for example the PROXY_SERVICE_OFFER information) in messages intended for T1 and T2.
  • a relay service medium for example the PROXY_SERVICE_OFFER information
  • the relay node can be configured for, on receipt of data indicating an acceptance of the first terminal to use the relay service (for example on receipt of a "PROXY_SERVICE_ACCEPT" option), check that this response from the first terminal corresponds to an offer sent by the relay node to this terminal.
  • the relay node can further be configured to determine whether the value of the field carrying a relay service offer identifier ("Offer_ID"), received among the data indicating an acceptance of the first terminal to use the relay service, corresponds to an offer identifier stored in memory, for example in a table for saving the identifiers of offers previously sent to terminals.
  • Offer_ID relay service offer identifier
  • the relay node may further be configured to reject (e.g. by ignoring) the first terminal's acceptance to use the relay service if no offer is found among those previously sent to terminals which correspond to the identifier received from the first terminal. For example, in the specific and non-limiting context of using the relay for the management of multiple paths for the QUIC communication between the two terminals, if no offer is found, then the relay node rejects this message and, consequently, does not modify its multipath management policy (s).
  • the relay node can further be configured to, when an offer is found among those previously sent to terminals which correspond to the identifier received from the first terminal, extracting data indicating a acceptance of the first terminal to use the relay service the token ("Token") or the "Challenge” as well as, where appropriate, other information characteristic of a relay service offer, and save them in memory, by example in a table of active QUIC connections for the first terminal (for example called “PROXY_SERVICE_PEERS”).
  • the relay node may further be configured to restrict the use of the received key or token to one. single IP address, single prefix, or single pair consisting of an IP address and a port number. In this case, only the requests sent to a particular address of the relay will be associated with a given token.
  • the message sent by the first terminal to indicate to the relay node an acceptance to use the services of the relay node can comprise an algorithm for distributing the traffic load between multiple paths intended for to be applied by the relay node.
  • the optionally selected algorithm can thus be used by the relay node for the management of QUIC communication between the first terminal and the second terminal, for example for the management of this communication via multiple available paths.
  • a terminal can negotiate the QUIC connection distribution algorithm. Certain connections associated with the same terminal can benefit from the resiliency service in the event of the unavailability of a primary path, while other connections from the same terminal can benefit from the "bonding" service.
  • the proposed method may include a reliability check of the relay node by the first terminal, performed before accepting to use the service of the relay node.
  • the invention can also be applied when a relay node is located on the terminal side Tl and another relay node is located on the terminal side T2: in this case, a PROXY_SERVICE_OFFER offer is inserted by the relay node located on the side of the terminal Tl in a message sent by terminal T2 to terminal Tl passing through this relay node located on the terminal side Tl, while a PROXY_SERVICE_OFFER offer is inserted by the relay node located on the side of terminal T2 in a message sent by terminal Tl to terminal T2 passing through this relay node located on the terminal T2 side.
  • Terminals such as smart telephones (“smartphone” in English) and personal computers are now capable of activating and using several logical interfaces linked to one or more physical interfaces. Such terminals are called “multi-interfaces” (“Multi-Interface”, or MIF in English).
  • IP addresses can then be assigned to these MIF terminals so that they can connect to different types of networks such as a fixed network, a mobile network or a WLAN network (Wireless LAN), simultaneously or later.
  • IPv4, IPv6 or both IPv4, IPv6 or both
  • IPv4 address unique IPv6 address of local scope
  • ULA Unique Local Address
  • IPv6 address of global scope Global Unicast Address”, or GUA in English
  • MIF The "MIF" characteristic is volatile, because the ability to use multiple interfaces depends on the conditions of connection to the network (s), the location of the device, or other factors.
  • a MIF terminal can in particular use the plurality of interfaces available to it during the establishment of a simple connection (that is to say, a connection established along a single path with a given party), or even after establishing a simple connection.
  • a terminal does not know a priori whether it is possible for it to use several distinct paths to establish a communication with a given correspondent; more precisely, the terminal only acquires this information (if any) at the end of a phase during which it attempts to establish communication with the correspondent using multiple paths.
  • a terminal When a terminal has several interfaces capable of connecting it to different access networks (for example, fixed, mobile, or WLAN), it then benefits from so-called “hybrid” access, because it combines different access network technologies.
  • the service offers concerning a terminal with hybrid access are based on the introduction into the network of functions allowing the aggregation of all the network connections of a terminal (for example: WLAN and 3G, ADSL, WLAN and 4G , or 4G and 5G).
  • link aggregation In the field of networks, the terms “link aggregation” generally designate a grouping of several links associated with as many (logical) interfaces as if it were a single link associated with a single interface, in particular with the aim of increasing the speed beyond the limits of a single link, but also to apply the same operating procedures to all the links thus aggregated (notion of “fate sharing” in English). Optionally, link aggregation also allows other interfaces to take over if a network link fails (redundancy principle). Link aggregation applies to any type of traffic carried along these links, including IP traffic.
  • Link aggregation can also be used to distribute traffic over several links.
  • the distribution of traffic between links that are the subject of an aggregation depends on various parameters.
  • the distribution of traffic depends for example on the type of traffic (for example TCP type traffic or UDP type traffic), or on the traffic engineering policy (specifying for example a required level of quality of service (in English, " Quality of Service ”, or“ QoS ”).
  • various aggregation modes can be considered, including a so-called “fallback” mode (consisting in using secondary paths in the event of unavailability of the primary paths), a so-called “associative” mode (consisting of use the resources associated with all or part of the available paths, the IP flows associated with the same application that can be distributed between several paths) and a so-called “comfort” mode (similar to the associative mode, except that the flows of 'a given application are not split across multiple paths, but are sent over a single path).
  • a so-called “fallback” mode consisting in using secondary paths in the event of unavailability of the primary paths
  • an so-called “associative” mode consisting of use the resources associated with all or part of the available paths, the IP flows associated with the same application that can be distributed between several paths
  • a so-called “comfort” mode similar to the associative mode, except that the flows of 'a given application are not split across multiple paths, but are sent over a single
  • a terminal having several network attachments, can have one or more IP addresses assigned to each of its physical or logical interfaces. It may also have only one interface, in which case it can be assumed that it is located behind a residential gateway connected to one or more networks and compatible with a link aggregation mechanism.
  • a gateway can be configured to refrain from exploiting a network link aggregation mechanism for certain networks, or under certain operating conditions (for example, in the event of overloading of network connection concentrators).
  • a device located on the path of the QUIC packets exchanged by two terminals T1 and T2
  • this relay inserts in a QUIC message intended for the terminal T1 information, for example called “PROXY_SERVICE_OFFER”, indicating the support of the QUIC relay service via multiple paths.
  • the relay service can allow the use of available multipath resources to improve the performance or resiliency of a QUIC connection.
  • this use of resources may include rewriting the source address of the packets received from the terminal T1 (respectively, the destination address of the packets destined for T1) in order to be able to route the packets via certain paths.
  • Figure 2c illustrates an example of a problem encountered in routing packets over multiple paths if the source address is not rewritten by a relay.
  • the terminal T1 (40a) is present in a LAN (42) connected via a CPE (41) to three networks (ADSL (43al), WLAN (43a2), and 4G (43a3)). Distinct addresses (or prefixes) (@IPpl, @ IPp2, @ IPp3) are allocated by each of these networks (43al, 43a2, 43a3) to the CPE (41). An address or a prefix (@IPtl) can be delegated to the terminal Tl (40a) from one of the prefixes allocated by the networks (ADSL (43al), WLAN (43a2), and 4G (43a3)).
  • the @IPtl address could be an address extracted from an IPv6 prefix of @IPpl.
  • the source address of a packet sent by the terminal T1 to the terminal T2 is @IPtl.
  • the relay node (41), on board the CPE decides to route this packet as is via the 4G network, then this packet will be blocked by this network for IP address spoofing prevention measures (in English " anti-spoofing ”). These measures consist in verifying that the machines connected to a network can only send IP data with a source address allocated by this network. In this case, the relay node (41) will not be able to use paths multiple, including a path passing through the 4G network, for QUIC communication between the terminals T1 and T2.
  • the relay node (41) can rewrite the source address of the packet with the @ IPp3 address, as shown in Figure 2d.
  • the relay node (41) can in fact decide to add a path to a connection, remove a path, change the address, change the port number, etc. These decisions are normally local to the relay and are not necessarily taken in consultation with the terminals T1 and T2.
  • the traffic distribution policies can be configured on the relay node, in order to allow it to distribute the traffic between the various available networks.
  • these policies may be configured by a service provider and / or by a user.
  • An example of a policy would be to use the radio resources only in the event of the unavailability of a fixed access network or when the available resources of the main access network (typically the wired network) no longer allow it to be used. the characteristic traffic of a given application, etc.
  • the traffic distribution policies can prove to be critical because an inadequate use of the available resources can induce a rapid consumption of the quota available on a given access link, or even cause a significant increase in the amount of the invoice to be paid. by the user (in the case where the relay node is on board a CPE, for example).
  • Controlling a traffic distribution policy is also important for an operator because it makes it possible in particular to minimize the risk of congestion of certain links (for example, the abusive use of a cellular connection by a relay can congest a cell to the detriment of single-interface mobile terminals).
  • the relay node P i can be responsible for inserting the information “PROXY_SERVICE_OFFER”. For example, the relay node can select the QUIC message (s) received from T2 and intended for T1 associated with the same QUIC connection which must / must be used to convey the information. "PROXY_SERVICE_OFFER”. To do this, the relay node maintains in one embodiment a table of active QUIC connections with management of the state of each of these connections to determine the maximum number of insertions. information by QUIC connection, by connection identifier, etc. For example, a relay can send a “PROXY_SERVICE_OFFER” offer in three different messages of a QUIC connection.
  • the relay node can be configured for, in the event of a refusal, explicit or implicit, of the (first) terminal to which it has sent a service offer to use multiple paths for the QUIC communication of this terminal, unilaterally decide on a traffic routing policy to be applied for the QUIC communication between the first terminal and the second terminal.
  • the relay node can be configured to, in this situation, disable the multipath exploitation mechanisms for that connection. Thus, if the original path used to establish the QUIC connection is no longer available, the relay node does not switch traffic to another path, as shown in Figures 2e and 2f.
  • FIG. 2e shows a first terminal T1 (30a) which has established a QUIC communication with a second terminal T2 (30b), as well as a relay node Pl i (31) located on the communication path QUIC, behind an NI network (32) vis-à-vis the first terminal T1 (30a), and behind an Ni l sub-network (33al) connected to the Internet network (33b) vis-à-vis the second terminal T2 (30b).
  • the first terminal T1 (30a) can, within the framework of an exchange of QUIC messages with the second terminal T2 (30b), transmit to the second terminal T2 (30b) a QUIC message (M1), then receive a QUIC message (M2a) from a QUIC message sent by the second terminal and in which the relay node Pl i (31) will have inserted service offer data relay (PROXY_SERVICE_OFFER) for using multiple paths managed by the relay node for QUIC communication between the first (Tl) and the second (T2) terminal.
  • M1 QUIC message
  • the first terminal T1 (30a) can refuse the service offer relay of use of multiple paths by inserting in a QUIC message (M3a) intended for the second terminal T2 (30b) offer refusal data.
  • service relay PROXY_SERVICE_DISCARD
  • the relay node Pl i (M3a) will then transmit the message QUIC (M3), coming from the first terminal T1 (30a), to the second terminal T2 (30b), after having extracted (and removed) from the received message (M3a) the response of the first terminal T1 (30a) to its multiple path use relay service offer.
  • the relay node may deactivate a multiple path use option for QUIC communication between the first (Tl) and second (T2) terminal, so that in the event of failure to transmit QUIC packets on the single path used by the first (Tl) and second (T2) terminals, a new message QUIC (M4) sent by the first terminal T1 (30a) to the second terminal T2 (30b), reaching the relay node Pl i (31), may not be transmitted successfully between the relay node Pl i (31) and the second terminal T2 (30b), as illustrated in FIG. 2f.
  • M4 new message QUIC
  • the first terminal (local terminal) (30a) can be configured to receive a message (M2a) from the communication established according to the QUIC protocol, and detecting in the received message the presence of data indicating the support by the relay node (31) of a QUIC relay service.
  • M2a message from the communication established according to the QUIC protocol
  • the data indicating the support by the relay node P i (31) of a relay service QUIC received by the first terminal (30a) can be, in one or more embodiments, included in a UDP option.
  • this data may comprise first identification data of the relay node (“Relay_ID”), as well as possibly, depending on the embodiment, first identification data of the relay node.
  • service offer (“Offer_ID”), first access data to the relay node (“Locator (s)”), and / or service description data (“Service Description”).
  • the PROXY_SERVICE_OFFER message can include a UDP option comprising a relay node identifier field (“Relay_ID”), and a service offer identifier field (“Offer_ID”), a relay node first locator field (“Locator (s) "), and / or a service description data field (" Service Description ").
  • the first terminal (30a) (local terminal) can further be configured for, upon receipt of data indicating the medium by the relay node P i (31) of a relay service QUIC, determine if the use of the relay service offered by the relay node Pl i (31) is accepted or not (or, alternatively, if the use is refused or not), and in the case where the use is accepted (or, in a variant, is not refused), send to the second terminal (remote terminal), a message of the communication established according to the QUIC protocol comprising data indicating an acceptance of the first terminal to use the service of QUIC relay, and in the case where the use is accepted (or, in a variant, is refused), send to the second terminal (remote terminal), a message of the communication established according to the QUIC protocol comprising data indicating a refusal from the first terminal to use the QUIC relay.
  • the data indicating an acceptance of the first terminal to use the QUIC relay service may include second identification data of the relay node which correspond to the first identification data of the relay node received. with data indicating support by the relay node of a relay service.
  • the first terminal (30a) can also be configured for, in the case where the use of the relay P i (31) is accepted (or, as a variant, is not refused) generate (for example randomly) a token and possibly a “Challenge”, and include this token and if applicable this “Challenge” in the data indicating an acceptance of the first terminal to use the QUIC relay service sent to the second terminal.
  • the first terminal (30a) can also be configured for, in the case where the use of the relay P i (31) is accepted (or, as a variant, is not refused) include in the data indicating an acceptance of the first terminal to use the QUIC relay service sent to the second terminal of the second service offer identification data corresponding to the first service offer identification data received with data indicating support by the relay node of a relay service.
  • the data indicating an acceptance of the first terminal to use the QUIC relay service and the data identifying a node relays that can be used for communication with the first terminal can be included in the same message sent over the connection established according to the QUIC protocol and sent by the first terminal to the second terminal.
  • the relay service offer message (for example the UDP option "PROXY_SERVICE_OFFER" as described above) comprises data indicating the support by the relay node of a service QUIC relay relay via multiple paths
  • the data indicating an acceptance of the first terminal to use the QUIC relay service may further include service description data indicating a traffic load balancing algorithm chosen by the first terminal for the communication established according to the QUIC protocol on multiple paths with the second terminal.
  • the latter on receipt of a QUIC message by a terminal (or by a relay node of the path), the latter checks whether one or more PROXY_SERVICE_OFFER (or PROXY_SERVICE_ACCEPT / PROXY_SERVICE_DISCARD for a node relay) are present in the received message.
  • this verification can include detection of the presence of additional information, for example by comparing the “IP Length” fields of the IP header and “UDP Length” of the header. UDP.
  • the PROXY_SERVICE_OFFER option (s) can thus be extracted from the message, and the terminal can then perform integrity checks on this (these) option (s). In one embodiment, the terminal ignores the PROXY_SERVICE_OFFER option if an anomaly is then detected.
  • the terminal can be configured to determine whether it can trust the relay node identified in the received data indicating support for a relay service. For example, in the case where the relay node having offered a relay service support is implemented within a CPE equipment to which the terminal is connected (for example by means of a LAN network or a network WLAN) as shown in Figures 2c and 2d, the terminal can determine that it can trust the CPE to which it is connected based on the IP address of the CPE.
  • the terminal can be configured with a list of trusted relays deployed by the IP connectivity provider, in which case the trust verification can be done based on the relay identification data received with the data indicating the support of a relay service (for example, a relay identifier ("Relay_ID”)).
  • a relay identifier for example, a relay identifier (“Relay_ID”).
  • Other trust verification mechanisms alternative or complementary to those described above, can be implemented by the terminal in the context of the embodiments of the proposed method.
  • the PROXY_SERVICE_OFFER option is ignored if the check concludes that the relay node is not a trusted element.
  • the terminal if the terminal does not wish to use the resources of the relay for the current QUIC communication, the terminal includes a UDP PROXY_SERVICE_DISCARD option in a message sent to the remote terminal.
  • this option may include one or more of the following:
  • Relay_ID identification data of the relay node corresponding to those possibly received in the data indicating the medium by the relay node of a relay service. These relay node identification data can for example correspond to a copy of the corresponding field included in the data indicating the support by the relay node of a relay service (for example in the UDP option PROXY_SERVICE_OFFER).
  • Offer_ID service offer identification data corresponding to those possibly received in the data indicating the medium by the relay node of a relay service. These service offering identification data may for example correspond to a copy of the corresponding field and included in the data indicating the support by the relay node of a relay service (for example in the UDP option PROXY_SERVICE_OFFER).
  • the terminal if the terminal accepts to use the resources of the relay for the current QUIC communication, the terminal includes a UDP option PROXY_SERVICE_ACCEPT in a message to the remote terminal.
  • this option may include a token (“Token”), that is to say a key generated, for example randomly, by the terminal, as well as one or more of the following elements :
  • Relay_ID identification data of the relay node corresponding to those possibly received in the data indicating the medium by the relay node of a relay service. These relay node identification data can for example correspond to a copy of the corresponding field included in the data indicating the support by the relay node of a relay service (for example in the UDP option PROXY_SERVICE_OFFER).
  • Offer_ID service offer identification data corresponding to those possibly received in the data indicating the medium by the relay node of a relay service.
  • This service offering identification data may for example correspond to a copy of the corresponding field included in the data indicating the support by the relay node of a relay service (for example in the UDP option PROXY_SERVICE_OFFER).
  • Service Description data indicating a traffic load distribution algorithm chosen by the terminal for this QUIC communication.
  • the relay node can be configured to determine to use a default configuration for that QUIC connection.
  • FIG. 3a illustrates an exemplary implementation of the method proposed according to one or more embodiments.
  • a first terminal T1 (50a) and a second terminal T2 (50b) can be configured to establish a QUIC communication (by establishing a communication according to the terms of the QUIC protocol) and to exchange (51a) messages of this QUIC communication.
  • the first terminal T1 (50a) can furthermore be configured to discover (51b) a relay node (Pl i) located on the communication path which is able to provide a service for the communication.
  • the first terminal T1 (50a) can be configured for, on receipt of a relay service offer for the QUIC communication between the first terminal T1 (50a) and the second terminal T2 (50b) from a node relay (Pl i) located on the path of the QUIC communication between the first terminal T1 (50a) and the second terminal T2 (50b), determine whether this offer is accepted or not.
  • the first terminal Tl (50a) in the case where the first terminal Tl (50a) accepts to use the service of the relay node, can send to the second terminal T2 (50b), during an establishment phase or during communication (51a) between the first terminal (50a) and the second terminal (50b), an encrypted relay information message comprising data identifying the relay node (PI 1 ) and a token intended to be supplied by the relay node (PI 1) to the second terminal (50b).
  • the first terminal T1 (50a) can be configured to offer the second terminal T2 (50b) to use the relay node in support of the QUIC communication between the two terminals (50a, 50b).
  • the first terminal can send (52), to the second terminal, a relay information message (“PATH_PROBE_TARGET” message in FIG. 4a) of the QUIC communication established between the first terminal and the second terminal.
  • the relay information message may include data identifying a relay node usable for communication with the first terminal.
  • the second terminal can receive, from the first terminal, an encrypted relay information message comprising a token and data identifying a relay node between the first terminal and the second terminal capable of providing a service for the communication between the first terminal and the second terminal.
  • the second terminal T2 can receive, from the first terminal, a relay information message (“PATH_PROBE_TARGET” message in FIG. 3a) from the QUIC communication established between the first terminal and the second terminal, the relay information message comprising data identifying a relay node usable for communication with the first terminal.
  • a relay information message (“PATH_PROBE_TARGET” message in FIG. 3a) from the QUIC communication established between the first terminal and the second terminal, the relay information message comprising data identifying a relay node usable for communication with the first terminal.
  • the relay information message advantageously makes it possible to provide the remote terminal, in the context of a QUIC communication with this remote terminal, with data concerning the use of a relay node for the QUIC communication.
  • the first terminal can send to the second terminal a message specific to the QUIC communication, a message which will be interpreted by the second. terminal as indicating that the first terminal offers to use one or more relay services for QUIC communication between the two terminals.
  • the QUIC communication between the two terminals may be multipath communication, or potentially become so through the relay service.
  • the relay information message may be interpreted by the second terminal as an offer to use paths. multiple, through the relay node, for QUIC communication with the first terminal.
  • the relay information message can thus include data identifying a relay node having access to a plurality of paths for communication between the first terminal and the second terminal, as illustrated in Figure 2d.
  • the data identifying the relay node can comprise data identifying the relay node, such as for example an identifier of the relay node allocated by the first terminal, or an identifier of the relay node communicated by the relay node to the first terminal.
  • the data identifying the relay node can further include data for accessing the relay node, such as an address of the relay node (for example an IP address, possibly combined with a port number). These relay node access data may correspond to access data communicated by the relay node to the first terminal.
  • the data identifying the relay node may further include one or more QUIC connection identifiers, for example as a list of one or more QUIC connection identifiers.
  • the data identifying the relay node can further include a “Challenge” and a token identical to those communicated by the first terminal to the relay node.
  • the second terminal On receipt of the relay information message, the second terminal can refuse to use the services of the relay identified in the relay information message, implicitly or explicitly depending on the chosen embodiment.
  • the explicit refusal can be communicated to the first terminal by sending a message refusing to use the relay node for communication with the first terminal.
  • the refusal message is a QUIC message (for example introduced under the name “PATH_PROBE_REJECT”) informing the first terminal of the refusal of the second terminal to use the relay node.
  • This rejection message can, in one embodiment, include an identifier of the relay node in order to distinguish the relay node object of the message in the event of possible use of several relay node, for example corresponding to a relay node identifier received by the second terminal in the message d relay information.
  • the first terminal can receive, from the second terminal, a message of the communication established according to the QUIC protocol for refusing to use a relay comprising data indicating a refusal by the second terminal to use the relay node for communication with the first terminal.
  • the data indicating a refusal to use the relay node may include relay node identification data corresponding to relay node identification data transmitted by the first terminal in the relay information message. .
  • the second terminal can accept to use the services of the relay identified in the relay information message, implicitly or explicitly depending on the embodiment. selected.
  • the explicit acceptance can be communicated to the first terminal by sending an acceptance message to use the relay node for communication with the first terminal.
  • the acceptance message is a QUIC message (eg called "PATH_PROBE_ACCEPT") communicating to the first terminal the acceptance of the second terminal to use the relay node.
  • This acceptance message can, in one embodiment, include an identifier of the relay node in order to distinguish the relay node that is the subject of the message in the event of possible use of several relay nodes, for example corresponding to a relay node identifier received by the second terminal in the relay information message.
  • the first terminal can receive, from the second terminal, a message of the communication established according to the QUIC acceptance protocol to use a relay comprising data indicating an acceptance by the second terminal to use the relay node for communication with the first terminal.
  • the data indicating an acceptance to use the relay node may include relay node identification data corresponding to relay node identification data transmitted by the first terminal in the relay information message. .
  • the first terminal (Tl) (or local terminal) communicates the identity of the relay in a possibly encrypted QUIC message to the second terminal (or remote terminal) (T2), for example using a new QUIC relay information frame, for example called “PATH_PROBE_TARGET”, a possible structure of which is illustrated by FIG. 3b.
  • the new QUIC frame (60) proposed for relay information may include, depending on the embodiments, one or more of the following fields:
  • a second field (60b) called "Locator (s)", which carries one or more locator (s) to reach the relay node.
  • a locator may for example be an IPv4 address, an IPv6 address or an IP address and port number.
  • this field corresponds to a copy of the "Locator (s)" field of the UDP PROXY_SERVICE_OFFER option transmitted by the relay node to the first terminal.
  • a third field (60c) called “Connection_ID (s)”, which describes a list containing one or more connection identifiers whose path involves the relay node.
  • the terminal can also include the identity of the relay when creating new connection identifiers.
  • the NEW_CONNECTION_ID frame is modified to associate a relay with a connection identifier.
  • the frame is modified to fill in the identifier (or identifiers) of relay nodes able to be involved when new connection identifiers are used.
  • FIG. 2g shows an example of a NEW_CONNECTION_ID frame modified to associate a relay with a connection identifier.
  • the PROXY_SERVICE_ACCEPT option may be included in the same QUIC message as that which carries the P ATH_PROB E_T ARGET frame.
  • the second terminal T2 (50b) can be configured to, upon receipt of the relay information message and data identifying the relay node, save in a table (53, “MP_PEER_TBL” table), for example stored in the memory of said terminal, the data identifying the relay node received.
  • a table 53, “MP_PEER_TBL” table
  • the MP_PEER_TBL table can be configured to store the identification data of the relay node in association with the access data to the relay node in the associated communication network, a second list of 'associated connection identifiers established on the basis of the first list of connection identifiers whose path involves the relay node, and with the token.
  • the second terminal T2 can be configured to, upon receipt of a QUIC frame of relay information (eg "PATH_PROBE_T ARGET"), proceed to the integrity checks specified for the QUIC protocol used, then extract the contents of the PATH_PROBE_TARGET frame. It can also be configured to save in a table (eg “MP_PEER_TBL”) the identity of the relay, the associated locators, the “Challenge”, and the security key (token or “Token”) as well as a list of associated connection identifiers.
  • a QUIC frame of relay information eg "PATH_PROBE_T ARGET”
  • MP_PEER_TBL the identity of the relay
  • the associated locators the associated locators
  • security key token or “Token”
  • the second terminal can be configured to store for communication the received token and a first quadruple comprising an address and a source port number, and an address and a destination port number. of the relay information message, and on detection, in a subsequent message of the communication from the first terminal, of a source address different from the source address of the first quadruplet, check with the relay node whether the subsequent message has passed through the relay node, and where appropriate, memorize for communication, a second quadruple comprising the address and the source port number and the address and the destination port number of the subsequent message.
  • the second quadruple can be stored while retaining the first quadruple.
  • Embodiments of the proposed method are described below in the non-limiting context in which the relay service is used for the implementation of multiple paths for a communication established according to the modalities of the QUIC protocol between a first terminal and a second terminal.
  • the relay node can send an offer message.
  • relay service for the management of multiple paths for QUIC communication for example in the form of a UDP option (for example "PROXY_SERVICE_OFFER”) inserted in a QUIC frame transmitted by a second terminal (called “remote") to a first terminal (called “local”)) to the local terminal, and receive in return acceptance data from the local terminal (for example a UDP option (for example “PROXY_SERVICE_ACCEPT”) inserted in a QUIC frame transmitted to the remote terminal) for G use of the relay for managing multiple paths for QUIC communication between the local terminal and the remote terminal, the acceptance data including validation data (for example a token or a key digital).
  • the relay node can extract the validation data therefrom, and save them in a memory, for example in the form of
  • the local terminal can then transmit to the remote terminal an information QUIC frame concerning the relay node (for example "PATH_PROBE_TARGET") comprising information data on the relay node, the information data comprising data from the relay node. identification of the relay node, the access data to the relay node, and the acceptance data (for example the "Challenge” or the token) previously communicated to the relay node.
  • the remote terminal can enter in a memory the information data on the relay node received from the local terminal, for example in the form of a table (for example called "MP_PEER_TABLE ").
  • the multiple path management and address verification operations will not be done between the two terminals live for these connection identifiers but between the terminal and the relay node according to the information. recorded in the table of active connections maintained by the relay node.
  • a new path eg a QUIC message comprising a quadruple ⁇ source address, source port, destination address, destination port ⁇
  • the remote terminal consults its table
  • the remote terminal sends a PATH_PROBE_REQUEST (Request_ID, [Peer ID, Connection_ID, External IP address, Extemal port number, Challenge ..]) message whose destination address is a relay locator.
  • PATH_PROBE_REQUEST Request_ID, [Peer ID, Connection_ID, External IP address, Extemal port number, Challenge ..]
  • PATH_PROBE_REQUEST includes the request identifier "Request_ID”, and optionally one or more of the following parameters: "Peer ID”, “Connection_ID”, “External IP address”, “External port number”, and a challenge ("Challenge") extracted of the MP_PEER_TABLE table.
  • the “Request_ID” field indicates a PATH_PROBE_REQUEST request identifier. This field is used to correlate a request and the associated response.
  • the "Peer ID” field is an optional field which indicates the relay identifier (Relay_ID) as previously communicated by a remote terminal. Field
  • Connection-ID is an optional field which indicates the identifier of the connection relayed by a relay.
  • the "Extemal IP address” field is an optional field that provides information on the source IP address of messages received from the terminal directly (i.e., without relay).
  • the “External port number” field is an optional field which provides information on the source port number of messages received from the live terminal.
  • the challenge included by the remote terminal in a PATH_PROBE_REQUEST () request is identical to that communicated beforehand by the source terminal.
  • the challenge is composed of one or more parameters such as the external IP address and “Challenge” or the external IP address and “Connection_ID”.
  • the included challenge can thus be structured according to the following form "parameter% parameter2% ". "%" Is used as a separator.
  • the term “challenge” is used with reference to the “Challenge” field or to that of the variant.
  • the relay node on receipt of the PATH_PROBE_REQUEST frame by the relay node, the latter checks whether an entry associated with this request is present in its table of active connections for the local terminal (PROXY_SERVICE_PEERS).
  • the relay node extracts the associated validation data, for example the associated token ("Token”), and includes it in a PATH_PROBE_REPLY message returned to the remote terminal , as well as the request identifier (“Request_ID”) extracted from the received PATH_PROBE_REQUEST frame.
  • the QUIC PATH_PROBE_REPLY frame includes the request identifier "Request_ID”, and optionally one or more of the following parameters: "Code” and "Token”.
  • the "Code” field indicates the result of the query.
  • the relay node can also ignore the request.
  • the remote terminal on receipt of the PATH_PROBE_REPLY message, compares the token (“Token”) received in the response with that maintained in its MP_PEER_TABLE table. The path is not validated if an anomaly is detected during the token verification operation.
  • the remote terminal can then use the associated resources and does not proceed with the connection migration.
  • the proposed method may further comprise, during the establishment of the communication between the first terminal and the second terminal or at any other time of the communication, indicating to the first terminal that the second terminal supports an extension of the QUIC protocol which allows the establishment of communications according to the QUIC protocol on multiple paths, even if only one path is available locally at the level of the second terminal.
  • the verification performed by the second terminal can comprise: sending a verification request message to the relay node comprising the source address of the second quadruplet or a challenge, receiving a message from response from the relay node comprising a token, and checking the coincidence between the token received from the relay node and the stored token.
  • the second terminal may further be configured to, if the two tokens match, use the second quadruplet for sending encrypted messages to the first terminal.
  • FIG. 4a shows an example of establishment of communication according to the QUIC protocol between a local terminal (Tl) and a remote terminal (T2), via a relay (Pl i) along an initial communication path (CCi), while FIG. 5b shows an example of establishment of communication according to the QUIC protocol via multiple paths.
  • the relay node (Pl i) uses an address (or a prefix) (@IPpl l) allocated by the sub-network (Ni l) through which the initial communication path passes.
  • the relay node (Pl i) uses two addresses (or prefixes) (@IPpl l and @IPpli) respectively allocated by the subnetworks (Ni l) and (Nli) through which the path respectively passes initial communication path (CCi) and the secondary communication path (CCs).
  • the example illustrated in FIG. 4b thus does not involve the local terminal (Tl) in the implementation of the QUIC multiple-path communication.
  • FIG. 4b is not limiting, in that the method proposed for the implementation of multiple paths for a QUIC communication using a relay node n ' is not limited to two paths, or the use of a single relay, but that it can be used for the implementation of two or more multiple paths for QUIC communication between two terminals using one or more relay nodes .
  • FIG. 5a illustrates an example of the architecture of a terminal for the implementation of the proposed method.
  • the device 100 comprises a controller 101, operably 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 data communication protocols (by wire or wireless), for example of the type WLAN, Ethernet, UMTS, LTE, or LTE-A.
  • 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 communications management module 104 is configured to send, to another terminal, a relay information message of a communication established according to a QUIC with the other terminal, the message of. relay information comprising data identifying a relay node usable for communication with the first terminal, and for receiving, from another terminal, such a relay information message.
  • the device 100 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 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 a combination of hardware and software elements, such as for example a software program intended to be used. loaded and executed on an FPGA type component.
  • FIG. 5b illustrates an example of the architecture of a relay node 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 QUIC 204 relay service module.
  • 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, UMTS, LTE, LTE-A.
  • the controller 201 is configured to drive the relay service module 204 and the communication interface 202 for the implementation of one or more embodiments of the proposed method.
  • the relay service module 204 is configured to implement the method proposed by a relay node.
  • the relay 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 relay node.
  • 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, a compact disc (CD), a digital video / versatile disc (DVD), a flash disk, 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.
  • 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 LPGA (Lield Programmable Gâte Array) type component.
  • the relay 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 a component of type LPGA.

Landscapes

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

Abstract

Un procédé de gestion d'une communication entre un premier terminal (Tl) et un deuxième terminal (T2) dans un réseau de communication est proposé, qui comprend, au premier terminal (Tl) : découvrir au moins un noeud relais (Pli) entre le premier terminal (Tl) et le deuxième terminal (T2), ledit noeud relais (Pli) étant apte à fournir au moins un service pour ladite communication, et si le premier terminal (Tl) accepte ledit service, émettre vers le deuxième terminal (T2), lors d'une phase d'établissement ou au cours de ladite communication, un message d'information de relais chiffré comprenant des données identifiant ledit au moins un noeud relais (Pli) et un jeton destiné à être fourni par ledit au moins un noeud relais (Pli) au deuxième terminal (T2).

Description

Description
Titre : 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é
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 le protocole QUIC.
Technique antérieure
[0002] Le développement récent des applications utilisables sur des terminaux multi- interfaces, tels que des téléphones intelligents (en anglais, « smartphones ») a suscité l’émergence de nouveaux protocoles de transport qui ont été proposés, standardisés et implémentés par la communauté Internet pour satisfaire les nouveaux besoins des applications.
[0003] Le protocole QUIC décrit dans le projet de spécification de l’Internet Engineering Task Lorce (IETL) intitulé « QUIC : A UDP-Based Multiplexed and Secure Transport » en est un exemple. Il a été initialement spécifié pour décharger le système d’exploitation des contraintes imposées par le support de la couche transport. 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. L’usage d’UDP permet en outre de mieux s’accommoder de la présence de pare-feux et de fonctions NAT (de l’anglais « Network Address Translation ») sur le chemin supportant une communication QUIC.
[0004] 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. Ainsi typiquement, un paquet QUIC comprend des données utiles chiffrées (en anglais, « Encrypted Payload », ou « EP ») et des données d’en-tête non chiffrées (en anglais, « Public Header », ou « PH »). Les données d’en-tête sont organisées en trois champs : un champ d’indicateurs binaires (en anglais « Flags », ou « F »), un champ d’identifiant de connexion (en anglais « Connection ID », ou « CID »), et un champ d’index de paquet (en anglais « Packet Number », ou « PN »).
[0005] Une communication (ou connexion) QUIC offre la possibilité de multiplexer différents canaux (en anglais « streams ») Chaque canal est identifié par un identifiant de canal (en anglais, « stream ID ») unique le temps que dure la communication QUIC. Les bits de poids faible de l’identifiant de canal indiquent la nature du canal. Le premier bit de poids faible indique l’initiateur du canal (client ou serveur), et le deuxième bit de poids faible permet de distinguer les canaux unidirectionnels des canaux bidirectionnels. On note que le protocole QUIC n’impose pas de limite concernant le nombre maximum de canaux ni la nature de ces canaux (unidirectionnels, bidirectionnels). En outre, un canal peut être établi à l’initiative du client ou du serveur. Les participants à une communication QUIC peuvent toutefois limiter le nombre de canaux ouverts par le terminal distant ainsi que le volume des données échangées, à l’aide de trames de contrôle envoyées à cet effet.
[0006] Les données échangées au titre d’un canal sont encapsulées dans une trame appelée « STREAM ». Un canal spécifique est dédié au chiffrement des échanges d’établissement de communication (« Handshake ») et à la négociation des options QUIC. La signalisation QUIC intègre des informations qui permettent de contrôler la congestion et de récupérer des paquets perdus, selon un mode de fonctionnement comparable à celui de TCP. Afin de supporter tout changement d’adresse IP sans avoir à clôturer une connexion QUIC en cours, le protocole QUIC ne s’appuie pas sur les adresses transport (adresse IP source, numéro de port source, adresse IP destination, numéro de port destination) mais sur l’identifiant CID de connexion. Le projet de spécification QUIC de l’IETL définit deux types de CID : Destination CID et Source CID.
[0007] En l’état actuel de ce projet, le protocole QUIC ne supporte qu’un mécanisme de migration de connexions qui permet de maintenir une connexion QUIC en cours en cas de modification d’une des adresses (ou numéros de port) des participants (incluant les changements d’adresses allouées par des fonctions NAT intermédiaires le cas échéant). La réception d’un message au titre d’une connexion en cours est une indication de migration de connexion. Ainsi, une migration de connexion peut consister à passer d’un quadruplet {adresse source, port source, adresse destination, port destination] à un autre. [0008] Les terminaux procèdent à la validation de la nouvelle adresse à l’aide de trames PATH_CHALLENGE et PATH_RESPONSE échangées entre les participants pour valider une migration de connexion. On note que le projet de spécification QUIC de l’IETF considère qu’un seul chemin est utilisé à la fois pour une même connexion QUIC.
[0009] En l’état actuel, le projet de spécification du protocole QUIC ne permet pas la fourniture, à des terminaux souhaitant établir une communication QUIC, de services supplémentaires gérés par le réseau de communication utilisé par lesdits terminaux et assurés par des éléments réseaux intermédiaires placés sur le chemin emprunté par la communication QUIC. Or, la présence de tels nœuds relais peut induire des modifications sur les ressources utilisées pour la communication QUIC et en particulier des modifications des adresses et/ou des numéros de port utilisés lors de la communication. Or, de telles modifications peuvent conduire à une instabilité de la communication QUIC. En effet, comme mentionné précédemment, seul un mécanisme de migration de connexion est prévu aujourd’hui dans le protocole QUIC en cas de changement d’adresse(s), et ce mécanisme impose au terminal distant de vérifier à chaque modification détectée que c’est l’autre terminal engagé dans la communication QUIC qui est à l’origine de cette modification. Cette vérification se fait au moyen de requêtes envoyées par le terminal distant qui, en présence de nœud(s) relais sur le chemin utilisé par la communication, peuvent être rejetées ou échouer.
Résumé
[0010] La présente divulgation vient améliorer la situation.
[0011] Selon un premier aspect, il est proposé un procédé de gestion d’une communication établie selon le protocole QUIC entre un premier terminal et un deuxième terminal connectés via un réseau de communication, le procédé comprenant, au premier terminal : découvrir au moins un nœud relais entre le premier terminal et le deuxième terminal, ledit nœud relais étant apte à fournir au moins un service pour ladite communication ; et si le premier terminal accepte ledit service, émettre vers le deuxième terminal, lors d’une phase d’établissement ou au cours de ladite communication, un message d’information de relais chiffré comprenant des données identifiant ledit au moins un nœud relais et un jeton destiné à être fourni par ledit au moins un nœud relais au deuxième terminal. [0012] Ainsi, le procédé proposé introduit avantageusement un schéma de découverte d’un nœud relais au sein d’un réseau de communication situé sur le chemin d’une communication entre deux terminaux, et de découverte des services offerts par ce nœud relais. Le schéma proposé permet aussi l’utilisation d’un tel nœud relais par deux terminaux en communication, par exemple établie selon les procédures du protocole QUIC sur le réseau. L’utilisation d’un nœud relais dans le cadre d’une communication QUIC ouvre la possibilité pour les terminaux de la communication de bénéficier de services, éventuellement offerts par le nœud relais et/ou accessibles aux terminaux par le biais du nœud relais, comme par exemple de services anti-virus, de détection de canaux couverts, d’inspection de paquets ou DPI (Deep Packet Insepection), de mitigation d’attaque de déni de service, etc.
[0013] La possibilité de faire intervenir un nœud relais dans une communication établie selon les procédures du protocole QUIC entre deux terminaux permet en outre à l’opérateur de réseau de mieux gérer la communication, et en particulier les ressources réseau affectées à la communication.
[0014] Dans un ou plusieurs modes de réalisation, découvrir ledit au moins un nœud relais comprend recevoir un message provenant du nœud relais ou provenant du deuxième terminal et ayant transité par ledit au moins un nœud relais, comprenant une indication dudit service fourni par ledit nœud relais et un identifiant dudit nœud relais.
[0015] Dans un ou plusieurs modes de réalisation, le procédé proposé comprend en outre : si le premier terminal accepte la fourniture dudit service par ledit nœud relais, émettre un message à destination du nœud relais ou à destination du deuxième terminal et transitant via ledit nœud relais, comprenant une indication destinée audit nœud relais de l’acceptation dudit service par le premier terminal et un jeton généré par le premier terminal.
[0016] Dans un ou plusieurs modes de réalisation, le message d’information de relais comprend en outre au moins un élément parmi une information de joignabilité du nœud relais permettant d’accéder audit nœud relais, au moins un identifiant d’au moins une communication entre le premier et le deuxième terminal empruntant un chemin impliquant le nœud relais et un défi généré par le premier terminal.
[0017] Dans un ou plusieurs modes de réalisation, le procédé proposé comprend en outre : vérifier une fiabilité du nœud relais avant d’accepter ledit service. [0018] Les schémas précités permettent avantageusement à un terminal QUIC de contrôler les services offerts par un relais QUIC, et de négocier les services à appliquer pour les communications associées à ce terminal.
[0019] Dans un ou plusieurs modes de réalisation, ledit service comprend un accès par le nœud relais à des chemins multiples pour supporter ladite communication entre le premier terminal et le deuxième terminal.
[0020] La fourniture d’un service de distribution de trafic via des chemins multiples par un nœud relais du réseau permet avantageusement à un opérateur de ce réseau de mieux contrôler les politiques de distribution de trafic via des chemins multiples dans le réseau, de telles politiques telles qu’activées par un terminal QUIC pouvant ne pas être optimales pour l’opérateur.
[0021] Cela permet en outre la mise en place de mécanismes de collaboration entre un terminal QUIC et un réseau d’opérateur pour l’établissement et la gestion des communications via des chemins multiples.
[0022] Dans un ou plusieurs modes de réalisation, ledit message comprend en outre un algorithme de répartition de charge de trafic entre lesdits chemins multiples destiné à être appliqué par le nœud relais.
[0023] Dans un ou plusieurs modes de réalisation, le procédé proposé comprend en outre : lors de l’établissement ou au cours de ladite communication entre le premier et le deuxième terminal, indiquer au deuxième terminal que le premier terminal supporte une extension du protocole QUIC qui permet l’établissement de ladite communication selon le protocole QUIC sur des chemins multiples, même si un seul chemin est disponible localement au niveau du premier terminal.
[0024] En effet, un terminal QUIC n’a pas de visibilité concernant les chemins multiples disponibles dans le réseau. Grâce au procédé proposé, une communication QUIC peut bénéficier des ressources associées à des chemins multiples, même si ces chemins multiples ne sont visibles ni du client, ni du serveur. Ceci permet d’améliorer l’usage des ressources dans le réseau, mais également d’améliorer la qualité d’expérience telle que perçue par le client (grâce à la capacité d’agréger la bande passante susceptible d’être utilisée par une communication QUIC, par exemple). [0025] Selon un autre aspect, il est proposé un procédé de gestion d’une communication établie selon le protocole QUIC entre un premier terminal et un deuxième terminal connectés via un réseau de communication, le procédé comprenant, au deuxième terminal, lors d’une phase d’établissement ou au cours de ladite communication : recevoir, en provenance du premier terminal, un message d’information de relais chiffré comprenant un jeton et des données identifiant au moins un nœud relais entre le premier terminal et le deuxième terminal apte à fournir au moins un service pour ladite communication.
[0026] Dans un ou plusieurs modes de réalisation, le procédé proposé comprend en outre : mémoriser pour ladite communication ledit jeton et un premier quadruplet comprenant une adresse et un numéro de port source, et une adresse et un numéro port destination du message d’information de relais ; sur détection, dans un message subséquent de ladite communication en provenance du premier terminal, d’une adresse source différente de l’adresse source du premier quadruplet : vérifier auprès du nœud relais si ledit message subséquent a transité par le nœud relais ; et le cas échéant, mémoriser pour la communication, un deuxième quadruplet comprenant l’adresse et le numéro de port source, et l’adresse et le numéro de port destination du message subséquent.
[0027] Dans un ou plusieurs modes de réalisation, le deuxième quadruplet est mémorisé tout en conservant le premier quadruplet.
[0028] Dans un ou plusieurs modes de réalisation, le procédé proposé comprend en outre : lors de l’établissement ou au cours de ladite communication entre le premier et le deuxième terminal, indiquer au premier terminal que le deuxième terminal supporte une extension du protocole QUIC qui permet l’établissement de communications selon le protocole QUIC sur des chemins multiples, même si un seul chemin est disponible localement au niveau du deuxième terminal.
[0029] Dans un ou plusieurs modes de réalisation, la vérification comprend : envoyer un message de demande de vérification au nœud relais comprenant l’adresse source du deuxième quadruplet ou un défi ; recevoir un message de réponse du nœud relais comprenant un jeton ; vérifier la coïncidence entre ledit jeton reçu du nœud relais et le jeton mémorisé. [0030] Dans un ou plusieurs modes de réalisation, le procédé proposé comprend en outre : si lesdits jetons coïncident, l’utilisation du deuxième quadruplet par le deuxième terminal pour l’envoi de messages chiffrés au premier terminal.
[0031] Selon un autre aspect, il est proposé un procédé de gestion d’une communication établie selon le protocole QUIC entre un premier terminal et un deuxième terminal, connectés via un réseau de communication, le procédé étant mis en œuvre par un nœud relais du réseau de communication situé entre le premier et le deuxième terminal et apte à fournir au moins un service pour ladite communication, ledit procédé comprenant : insérer dans au moins un message destiné au premier terminal, provenant du deuxième terminal et transitant par ledit nœud relais des données indiquant le support par ledit nœud relais dudit service, lesdites données comprenant un identifiant du nœud relais.
[0032] Dans un ou plusieurs modes de réalisation, lesdites données sont comprises dans une option UDP (User Datagram Protocol).
[0033] Dans un ou plusieurs modes de réalisation, ledit service comprend un accès par le nœud relais à des chemins multiples qui permettent de supporter ladite communication entre le premier terminal et le deuxième terminal.
[0034] Dans un ou plusieurs modes de réalisation, lesdites données comprennent en outre l’un au moins parmi un identifiant d’offre de service, au moins une information de joignabilité du nœud relais permettant d’accéder audit nœud relais, et des données descriptives du service fourni par le nœud relais.
[0035] Dans un ou plusieurs modes de réalisation, le procédé proposé comprend en outre : recevoir en provenance du premier terminal un message de ladite communication comprenant une indication d’une acceptation par le premier terminal du service fourni par le nœud relais et un jeton généré par le premier terminal ; mémoriser dans une table de communications actives pour le premier terminal ledit jeton associé avec ladite communication.
[0036] Dans un ou plusieurs modes de réalisation, le procédé proposé comprend en outre : suite à une acceptation du service fourni par le nœud relais par le premier terminal, modifier une adresse source ou destination et/ou un numéro de port source ou destination d’un message provenant du premier terminal ou du deuxième terminal, destiné au deuxième terminal ou au premier terminal et transitant par le nœud relais qui se charge de relayer ledit message vers le deuxième terminal.
[0037] Ce mécanisme permet avantageusement de répondre à la problématique de modifications d’adresses ou de numéros de port tels qu’alloués par un nœud relais, modifications qui peuvent conduire à une instabilité de la communication QUIC car le terminal distant doit vérifier à chaque modification d’adresse source que le terminal QUIC est à l’origine d’une modification. Les requêtes utilisées à cet effet peuvent être rejetées (à case de politique de « rate-limit » par le terminal source) ou échouer car le terminal n’a pas la connaissance des modifications effectuées dans le réseau.
[0038] 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 du procédé proposé dans la présente description.
[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.
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. 1
[0043] [Fig. 1] illustre un exemple de système de communication pour la mise en œuvre d’un ou plusieurs modes de réalisation.
Fig. 2a
[0044] [Fig. 2a] illustre un exemple de mise en œuvre du procédé proposé selon un ou plusieurs modes de réalisation.
Fig. 2b
[0045] [Fig. 2b] illustre un exemple d’encapsulation d’une option d’information d’annonce de service relais dans un paquet UDP selon un ou plusieurs modes de réalisation.
Fig. 2c
[0046] [Fig. 2c] illustre un exemple de mise en œuvre du procédé proposé selon un ou plusieurs modes de réalisation. Fig. 2d
[0047] [Fig. 2d] illustre un exemple de mise en œuvre du procédé proposé selon un ou plusieurs modes de réalisation.
Fig. 2e
[0048] [Fig. 2e] illustre un exemple de mise en œuvre du procédé proposé selon un ou plusieurs modes de réalisation.
Fig. 2f
[0049] [Fig. 2f] illustre un exemple de mise en œuvre du procédé proposé selon un ou plusieurs modes de réalisation.
Fig. 2g
[0050] [Fig. 2g] illustre un exemple de trame NEW_CONNECTION_ID modifiée pour associer un relais avec un identifiant de connexion selon un ou plusieurs modes de réalisation.
Fig. 3a [0051] [Fig. 3a] illustre un exemple de mise en œuvre du procédé proposé selon un ou plusieurs modes de réalisation.
Fig. 3b
[0052] [Fig. 3b] illustre une trame QUIC d’information de relais selon un ou plusieurs modes de réalisation.
Fig. 4a
[0053] [Fig. 4a] illustre un exemple d’établissement d’un chemin initial emprunté par une communication QUIC selon un ou plusieurs modes de réalisation.
Fig. 4b
[0054] [Fig. 4b] illustre un exemple d’établissement d’un chemin initial et d’un chemin secondaire empruntés par une communication QUIC selon un ou plusieurs modes de réalisation.
Fig. 5a
[0055] [Fig. 5a] illustre un exemple d’architecture d’un terminal selon un ou plusieurs modes de réalisation.
Fig. 5b
[0056] [Fig. 5b] illustre un exemple d’architecture d’un nœud relais selon un ou plusieurs modes de réalisation.
Description des modes de réalisation
[0057] 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.
[0058] La présente description fait référence à des fonctions, unités, modules et illustrations de diagrammes des méthodes et dispositifs selon un ou plusieurs modes de réalisation. Chacun des fonctions, modules, 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, 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 (tel que par exemple un support de stockage informatique (clés USB, CD-ROM, DVD, carte mémoire,...) ou un support de communication), 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. Les instructions peuvent comprendre du code de tout langage de programmation informatique ou élément de programme informatique.
[0059] 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 équipements 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.
[0060] 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 équipements, é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 filaire, des connexions de type sans fil, de type cellulaire, ou toute combinaison de ces différents réseaux. [0061] Les termes « couplé de manière opérationnelle », « couplé », « monté », « connecté » font référence à des couplages, connexions, montages, qui peuvent être directs ou indirects, et comprennent notamment des connexions entre équipements électroniques ou entre des portions de tels équipements qui permettent des opérations et fonctionnements tels que décrits dans la présente description. Il peut s’agir de connections ou de couplages physiques ou mécaniques, ou via une ou plusieurs connexion(s) filaire(s) et/ou sans-fil
[0062] Le terme « terminal » est utilisé dans la présente description pour désigner toute entité telle qu’une entité logicielle apte à fonctionner comme point d’extrémité d’une communication établie selon les modalités du protocole QUIC. Pour une communication donnée, un terminal qui met en œuvre le protocole QUIC (aussi désigné par « terminal QUIC » par la suite) peut agir en tant que client QUIC, serveur QUIC, ou les deux. Les exemples de terminaux incluent, de manière non limitative, des terminaux intelligents (en anglais, « smartphones »), des ordinateurs personnels (en anglais, « Personal Computer » ou « PC »), des tablettes, des serveurs du réseau Internet, etc.
[0063] 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.
[0064] 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 », dont l’implémentation par Google est parfois désignée par « gQUIC » (Google QUIC), y compris les versions existantes de ces spécifications ou projets de spécifications et leurs évolutions. Plus généralement, QUIC dénote tout protocole de transport encapsulé sur un autre protocole de transport de type UDP ou UDP-lite (Lightweight User Datagram Protocol) mais dont les primitives et la charge utile sont complètement chiffrées. [0065] La figure 1 illustre un exemple de système de communication (20) dans lequel un ou plusieurs modes de réalisation des procédés et dispositifs proposés peuvent être mis en œuvre.
[0066] Le système (20) comprend un premier terminal Tl (20a) en communication avec un deuxième terminal T2 (20b) par l’intermédiaire d’un premier réseau (22) auquel le premier terminal est connecté, d’un nœud relais (en anglais, « proxy » ou « relay ») PI (21) connecté au premier réseau (22) ainsi qu’à un deuxième réseau (23), et du deuxième réseau (23) auquel le deuxième terminal T2 (20b) est connecté. A titre d’exemple non limitatif, le premier réseau (22) peut être un réseau local (LAN) dans lequel le terminal Tl est présent, et le deuxième réseau peut être un réseau étendu (WAN) (comprenant un réseau sans fil WLAN, un réseau cellulaire (2G, 3G, 4G et/ou 5G), un réseau ADSL, un réseau d’accès fibre (FTTH/FTTC) ou toute combinaison de ces derniers), dans lequel le terminal T2 est présent. Le nœud relais peut être mis en œuvre dans une passerelle d’accès, par exemple de type CPE (de l’anglais « Customer Premises Equipment ») lorsque la passerelle est résidentielle.
[0067] Dans un ou plusieurs modes de réalisation, le premier terminal Tl et le deuxième terminal T2 peuvent effectuer des communications selon le protocole QUIC (ou « communications QUIC » par souci de simplification dans la suite de la description), c’est-à-dire établir une connexion selon les modalités prévues par le protocole QUIC et échanger des données en utilisant cette connexion. Un nœud relais PI peut être situé sur le chemin des messages QUIC (c.-à-d. conformes au protocole QUIC) échangés lors de la communication QUIC entre le premier terminal Tl et le deuxième terminal T2.
[0068] Dans un ou plusieurs modes de réalisation, le procédé proposé comprend, à un premier terminal pour lequel une communication QUIC est établie avec un deuxième terminal, la découverte d’au moins un nœud relais entre le premier terminal et le deuxième terminal, le nœud relais étant apte à fournir au moins un service pour la communication entre le premier terminal et le deuxième terminal. Les nœuds relais peuvent offrir divers services tels que des services d’anti- virus, de détection de canaux couverts, d’inspection de paquets ou DPI, de mitigation d’attaque de déni de service, etc.
[0069] Dans un mode de réalisation, la découverte d’un nœud relais peut comprendre la réception d’un message en provenance du nœud relais, ou en provenance du deuxième terminal et ayant transité par le nœud relais, comprenant une indication du service fourni par le relais et un identifiant du nœud relais.
[0070] On décrit ci-après des schémas de découverte d’un nœud relais (et des services qu’il supporte) par un terminal selon un ou plusieurs modes de réalisation, en référence aux figures 2a à 2d.
[0071] La figure 2a illustre un exemple de système de communication (30) comprenant un premier terminal Tl (30a) en communication selon le protocole QUIC avec un deuxième terminal T2 (30b) par l’intermédiaire d’un premier réseau NI (32) auquel le premier terminal est connecté, d’un nœud relais Pl i (31) connecté au premier réseau (32) ainsi qu’à un deuxième réseau comprenant une pluralité de sous-réseaux (33al - 33ai) connectés au réseau Internet (33b), et du deuxième réseau auquel le deuxième terminal T2 (30b) est connecté. A titre d’exemple non limitatif, le premier réseau (32) peut être un réseau local (LAN) dans lequel le terminal Tl est présent. Le nœud relais (31) peut être mis en œuvre dans une passerelle d’accès, par exemple de type CPE.
[0072] Dans un ou plusieurs modes de réalisation, le nœud relais (31) peut être configuré pour fournir un service comprenant un accès par le nœud relais à des chemins multiples qui permettent de supporter la communication entre le premier terminal et le deuxième terminal.
[0073] Dans un ou plusieurs modes de réalisation, le premier terminal Tl (30a) initialise une communication QUIC vers le deuxième terminal T2(30b) tout en indiquant qu’il supporte les extensions QUIC via des chemins multiples. Pour ce faire, le premier terminal TA (30a) peut notamment envoyer une nouvelle trame QUIC, appelée ici MP_STATUS(Status=Enabled) dans un message de contrôle au deuxième terminal T2 (30b). Préférentiellement, le premier terminal Tl envoie cette trame y compris si un seul et même chemin est disponible localement au niveau du premier terminal Tl (par exemple une seule interface réseau est activée sur le terminal Tl) : en effet, des chemins multiples peuvent être offerts par d’autres éléments du réseau comme par exemple par le nœud relais (31) ou peuvent apparaître au gré de l’évolution du réseau. En négociant au préalable le support des extensions QUIC via des chemins multiples entre les terminaux Tl et T2, on peut ainsi éviter en cas de changement du quadruplet (adresse source, numéro de port source, adresse destination, numéro de port destination) utilisé pour la communication, une migration de la connexion. [0074] Le deuxième terminal T2 peut alors confirmer l’activation des extensions QUIC via des chemins multiples en répondant avec également une trame MP_STATUS(Enabled). Les messages de la communication QUIC entre le premier terminal Tl et le deuxième terminal T2 peuvent alors être échangés via plusieurs chemins.
[0075] Si en revanche, aucune trame MP_STATUS(Enabled) n’est reçue du terminal T2, le terminal Tl désactive les extensions QUIC via des chemins multiples. Dans ce cas, en cas de modification de quadruplet (adresse source, numéro de port source, adresse destination, numéro de port destination) utilisé pour une communication, les terminaux procède à une migration de la communication QUIC conformément à la spécification actuelle du protocole QUIC.
[0076] On note que la trame MP_STATUS peut être utilisée pour véhiculer d’autres informations quant au support par les terminaux de chemins multiples. Ainsi on peut prévoir d’autres valeurs pour le champ Status comme par exemple une valeur « Unsupported » indiquant que les extensions QUIC via des chemins multiples ne sont pas supportées par le terminal ou encore une valeur « Disabled » indiquant que les extensions QUIC via des chemins multiples sont désactivées par le terminal.
[0077] On note par ailleurs que la trame MP_STATUS peut être envoyée à l’initialisation de la communication QUIC avec le terminal T2, mais également plus généralement, à tout moment de la communication. Le terminal Tl comme le terminal T2 peuvent être à l’origine de l’envoi de cette trame. De même, les deux terminaux peuvent à tout moment désactiver le support des extensions QUIC via des chemins multiples en utilisant la trame MP_STATU S (Disabled) .
[0078] En référence à la figure 2a, dans un ou plusieurs modes de réalisation, le premier terminal Tl (30a) et le deuxième terminal T2 (30b) échangent des messages QUIC dans le cadre d’une communication selon le protocole QUIC établie entre ces deux terminaux. La figure 3a illustre un exemple de séquence de transmissions de messages QUIC, dans laquelle le premier terminal Tl (30a) envoie un premier message QUIC Ml au deuxième terminal T2 (30b), le deuxième terminal T2 (30b) envoie un deuxième message QUIC M2 au premier terminal Tl (30a), puis le premier terminal Tl (30a) envoie un troisième message QUIC M3 au deuxième terminal T2 (30b). [0079] Dans un ou plusieurs modes de réalisation, le nœud relais Pl i (31) est configuré pour insérer, dans un message destiné au premier terminal et provenant du deuxième terminal et transitant par le nœud relais, des données indiquant le support par le nœud relais du service, les données comprenant un identifiant du nœud relais.
[0080] Dans un ou plusieurs modes de réalisation, le nœud relais Pl i (31), placé sur le chemin de la communication selon le protocole QUIC entre le premier terminal Tl (30a) et le deuxième terminal T2 (30b) (autrement dit, capable d’intercepter des messages échangés entre les deux terminaux), transmet au premier terminal un message (PROXY_SERVICE_OFFER) de la communication selon le protocole QUIC qui comprend des données indiquant le support par le nœud relais Pl i (31) d’un service de relais QUIC, par exemple une indication du service que le nœud relais peut fournir et un identifiant du nœud relais. Le message PROXY_SERVICE_OFFER permet au nœud relais Pl i (31) d’indiquer au premier terminal Tl (30a) qu’il peut fournir un ou des services de relais dans le cadre de la communication QUIC entre le premier terminal et le deuxième terminal.
[0081] Dans un ou plusieurs modes de réalisation, les données indiquant le support par le nœud relais PI 1 (31) du service de relais QUIC sont incluses dans une option UDP.
[0082] Par exemple, une information d’annonce de service relais peut être insérée par un relais dans une nouvelle option UDP, par exemple appelée PROXY_SERVICE_OFFER, comme illustré sur la figure 2b. La figure 2b montre l’encapsulation d’une option d’information d’annonce de service relais (PROXY_SERVICE_OFFER) dans un datagramme UDP. Le paquet IP (35) illustré sur la figure comprend un en-tête IP (35a) et un datagramme UDP comprenant un en-tête UDP (36a), des données QUIC (36b), et des options UDP (36c) dont une option « PROXY_SERVICE_OFFER » (36c 1) et une seconde option UDP (36c2). L’utilisation d’une option UDP permet avantageusement de s’affranchir des contraintes imposées par le chiffrement des données échangées selon le protocole QUIC.
[0083] En outre, l’option PROXY_SERVICE_OFFER peut avantageusement être insérée à n’importe quel moment de la durée de la connexion QUIC entre le premier terminal et le deuxième terminal. [0084] Dans un ou plusieurs modes de réalisation, une ou plusieurs options PROXY_SERVICE_OFFER peuvent être présentes dans un même message. Ces options peuvent par ailleurs être insérées par un même nœud relais ou par plusieurs nœuds relais.
[0085] Dans un ou plusieurs modes de réalisation, les données indiquant le support par le nœud relais peuvent comprendre, outre l’identifiant du nœud relais, l’un au moins parmi un identifiant d’offre de service, au moins une information de joignabilité du nœud relais (c’est à dire les données permettant d’accéder au nœud relais telles qu’une adresse IP, aussi désignées par « localisateurs » dans la suite), et des données descriptives du service fourni par le nœud relais.
[0086] Ainsi, dans un ou plusieurs modes de réalisation, les données indiquant le support par le nœud relais Pl i (31) du service de relais QUIC peuvent comprendre un ou plusieurs premiers localisateurs du nœud relais (Locator(s)), ainsi qu’ éventuellement, en fonction du mode de réalisation, un identifiant d’offre de service (« Offer_ID »), un identifiant du nœud relais (« Relay_ID »), et/ou des données de description de service (« Service Description »). Par exemple, l’information d’annonce de service relais peut être insérée dans une option PROXY_SERVICE_OFFER comprenant un champ portant un identifiant du nœud relais (« Relay_ID ») et éventuellement un ou plusieurs parmi un champ portant un identifiant d’offre de service (« Offer_ID »), un champ portant des localisateurs du nœud relais (« Locator(s) ») et un champ portant des données de description de service (« Service Description »).
[0087] Dans un ou plusieurs modes de réalisation, l’option PROXY_SERVICE_OFFER peut être structurée selon un format TLV (Type, Longueur, Valeur). Le champ « Valeur » peut inclure au moins une adresse IP, utilisée pour joindre le nœud relais. Par exemple, le champ « Valeur » peut comprendre dans un mode de réalisation les éléments suivants :
[0088] Un premier champ (« Relay_ID »), portant un identifiant pour identifier le nœud relais ayant inséré l’option. Cette information est utile en cas de présence de plusieurs relais dans un même chemin. Cet identifiant peut aussi être utilisé pour des besoins d’identification. Dans ce cas, l’identifiant est généré selon un formalisme connu des terminaux. L’algorithme SHA-256 peut par exemple être utilisé pour produire un hash sur la base de clés de sécurité publiques d’un relais. [0089] Un deuxième champ (« Offer_ID »), portant un identifiant d’offre de service de relais. Cet identifiant peut avantageusement être utilisé pour corréler les messages envoyés par un nœud relais et les réponses reçues d’un terminal, comme décrit plus en détails ci- dessous. Ce faisant, le nœud relais contrôle les terminaux auxquels il peut offrir son service. Cet identifiant sera de préférence généré d’une manière aléatoire.
[0090] Un troisième champ (« Locator(s) ») portant un ou plusieurs localisateurs pour joindre le nœud relais, un localisateur peut par exemple être, en fonction du mode de réalisation, une adresse IPv4, une adresse IPv6 ou une adresse IP et un numéro de port.
[0091] Un quatrième champ (« Service Description ») portant la description des services offerts par le relais. Par exemple, ce champ indique une liste comprenant un ou plusieurs algorithmes de répartition de charge de trafic supportés par le nœud relais, et/ou toute information caractéristique du service relais. Ce quatrième champ permet ainsi d’inviter le premier terminal à choisir un service de la liste. Dans un mode de réalisation, le nœud relais peut être configuré pour choisir un service par défaut si aucun choix n’est retourné pour la connexion QUIC par le premier terminal.
[0092] Un contrôle de l’intégrité du contenu de l’option PROXY_SERVICE_OFFER peut être effectué par le premier terminal conformément au protocole QUIC utilisé, par exemple à l’aide du « checksum UDP » ou tout autre mécanisme de contrôle d’intégrité du contenu adapté, comme la définition d’un champ « HMAC » qui transporte le condensé du contenu de l’option PROXY_SERVICE_OFFER (c’est-à-dire l’application d’une fonction « keyed Hashed Message Authentication Code » (HMAC)). Un tel contrôle d’intégrité constitue une vérification d’une fiabilité du nœud relais au sens de l’invention. D’autres contrôles peuvent être envisagés en variante.
[0093] Dans un ou plusieurs modes de réalisation, les données descriptives du ou des service(s) foumi(s) par le nœud relais peuvent être incorporées par le nœud relais dans un message de la communication établie selon le protocole QUIC reçu, en provenance du deuxième terminal, et à destination du premier terminal. Par exemple, en référence à la figure 2a, le nœud relais Pl i (31) peut insérer dans le message M2 en provenance du deuxième terminal (30b) et à destination du premier terminal (30a) une offre de support relais (offre de service relais), sous la forme d’un message PROXY_SERVICE_OFFER. Ainsi, le message M2a reçu par le premier terminal Tl (30a) comprend des données (PROXY_SERVICE_OFFER) insérées par le nœud relais Pl i (31) et indiquant le support par ce nœud relais d’un service de relais.
[0094] L’utilisation d’un message transmis par un terminal distant (le deuxième terminal T2) vers un terminal local (le premier terminal Tl) au nœud relais Pl i pour y insérer des données d’offre de service relais permet avantageusement de limiter la signalisation associée à la transmission des données d’offre de service relais. Le nœud relais profite en effet d’un message QUIC transmis au terminal Tl pour lui transmettre des données d’offre de service.
[0095] Dans un ou plusieurs modes de réalisation, le premier terminal Tl (30a) peut être configuré pour, suite à la réception de données indiquant le support par le nœud relais Pl i (31) d’un service de relais, répondre au nœud relais Pl i (31) en indiquant qu’il accepte ou refuse, selon les cas, d’utiliser le(s) service(s) de relais offert(s) par le nœud relais Pl i (31).
[0096] Dans le cas où le premier terminal Tl (30a) refuse d’utiliser le service de relais offert par le nœud relais Pl i (31), il peut transmettre au nœud relais un message QUIC comprenant des données (par exemple un message « PROXY_SERVICE_DISCARD ») indiquant son refus d’utiliser le service de relais. Dans ce cas, le nœud relais pourra recevoir, en provenance du premier terminal, un message QUIC comprenant des données indiquant un refus d’utiliser le service de relais. Dans un ou plusieurs modes de réalisation, les données indiquant son refus d’utiliser le service de relais pourront comprendre l’identifiant du nœud relais et/ou l’identifiant d’offre de service que le premier terminal Tl (30a) aura reçus dans les données indiquant le support d’un service de relais.
[0097] Dans le cas où le premier terminal Tl (30a) accepte d’utiliser le service de relais offert par le nœud relais Pl i (31), il peut émettre un message à destination du nœud relais Pl i (31), ou à destination du deuxième terminal et transitant via le nœud relais Pl i (31), comprenant une indication destinée au nœud relais Pl i (31) de l’acceptation du service par le premier terminal Tl (30a), et un jeton généré par le premier terminal Tl (30a).
[0098] Par exemple, dans un ou plusieurs modes de réalisation, dans le cas où le premier terminal Tl (30a) accepte d’utiliser le service de relais offert par le nœud relais PI 1 (31), il peut transmettre au nœud relais un message QUIC comprenant des données indiquant son acceptation d’utiliser le service de relais. [0099] Dans ce cas, le nœud relais pourra recevoir, en provenance du premier terminal, un message QUIC comprenant des données indiquant une acceptation d’utiliser le service de relais.
[0100] Dans un ou plusieurs modes de réalisation, le message d’information de relais pourra comprendre au moins un élément parmi une information de joignabilité du nœud relais permettant d’accéder au nœud relais, un identifiant d’une communication entre le premier et le deuxième terminal empruntant un chemin impliquant le nœud relais, et un défi généré par le premier terminal.
[0101] Dans un ou plusieurs modes de réalisation, les données indiquant son acceptation d’utiliser le service de relais pourront comprendre l’identifiant du nœud relais et un jeton généré par exemple aléatoirement par le premier terminal. Dans un ou plusieurs modes de réalisation, les données indiquant son acceptation d’utiliser le service de relais pourront en outre comprendre l’identifiant d’offre de service et/ou tout ou partie des données de description de service que le premier terminal Tl (30a) aura reçus dans les données indiquant le support d’un service de relais, ainsi qu’un défi (ou « Challenge ») généré, par exemple aléatoirement, par le premier terminal.
[0102] Ainsi, dans un ou plusieurs modes de réalisation, le nœud relais pourra être configuré pour recevoir, en provenance du premier terminal, un message de la communication entre le premier terminal et le deuxième terminal comprenant une indication d’une acceptation par le premier terminal du service fourni par le nœud relais et un jeton généré par le premier terminal, puis mémoriser, dans une table de communications actives pour le premier terminal, le jeton reçu, en association avec la communication.
[0103] Dans un ou plusieurs modes de réalisation, le nœud relais pourra être en outre configuré pour, suite à une acceptation du service fourni par le nœud relais par le premier terminal, modifier une adresse source ou destination et/ou un numéro de port source ou destination d’un message provenant du premier terminal ou du deuxième terminal, destiné au deuxième terminal ou au premier terminal, respectivement, et transitant par le nœud relais qui se charge de relayer ledit message vers le deuxième terminal.
[0104] Dans un ou plusieurs modes de réalisation, dans le cas où le premier terminal refuse d’utiliser le service de relais offert par le nœud relais, il peut insérer dans un message QUIC envoyé au deuxième terminal des données indiquant un refus d’utiliser le service de relais. Dans ce cas, le nœud relais recevra, en provenance du premier terminal, un message QUIC à destination du deuxième terminal qui comprend des données (par exemple « PROXY_SERVICE_DISCARD ») indiquant un refus du premier terminal d’utiliser le service de relais.
[0105] Par exemple, dans un ou plusieurs modes de réalisation, dans le cas où le premier terminal Tl (30a) accepte d’utiliser le service de relais offert par le nœud relais PI 1 (31), il peut insérer dans un message QUIC (M3) envoyé au deuxième terminal T2 (30b) des données (par exemple « PROXY_SERVICE_ACCEPT ») indiquant une acceptation d’utiliser le service de relais. Dans ce cas, le nœud relais recevra, en provenance du premier terminal, un message QUIC à destination du deuxième terminal comprenant des données (par exemple « PROXY_SERVICE_ACCEPT ») indiquant une acceptation du premier terminal d’utiliser le service de relais.
[0106] L’utilisation d’un message transmis par le terminal local (le premier terminal Tl) vers le terminal distant (le deuxième terminal T2) pour y insérer des données d’indication d’acceptation ou de refus, selon le cas, de service relais permet avantageusement de limiter la signalisation associée à la transmission d’un réponse explicite à l’offre de service relais. Le terminal local Tl profite en effet d’un message QUIC transmis au terminal distant T2 pour transmettre au nœud relais Pl i des données d’acceptation ou de refus de service relais.
[0107] Comme évoqué précédemment, dans un ou plusieurs modes de réalisation, le premier terminal peut être configuré pour, lors de l’établissement de la communication entre le premier et le deuxième terminal ou à tout autre moment lors de la communication, indiquer au deuxième terminal que le premier terminal supporte une extension du protocole QUIC qui permet l’établissement de la communication selon le protocole QUIC sur des chemins multiples, même si un seul chemin est disponible localement au niveau du premier terminal.
[0108] Dans un ou plusieurs modes de réalisation, le nœud relais peut recevoir, en provenance du premier terminal, un message (M3a) de la communication établie selon le protocole QUIC à destination du deuxième terminal, comprenant des données (par exemple « PROXY_SERVICE_ACCEPT ») indiquant que le premier terminal accepte le service relais. Suite à la réception de ce message, le nœud relais peut modifier (M3a -> M3) le message de la communication établie selon le protocole QUIC pour y supprimer les données indiquant que le premier terminal accepte le service relais, puis transmettre le message modifié (M3) au deuxième terminal.
[0109] Dans un ou plusieurs modes de réalisation, le nœud relais peut en outre être configuré pour transmettre les données indiquant le support par le nœud relais d’un service de relais au deuxième terminal.
[0110] Dans un ou plusieurs modes de réalisation, le nœud relais peut être configuré pour déterminer que le premier terminal n’est pas intéressé par le service de relais, dans le cas où aucune réponse au message annonçant le support par le nœud relais d’un service de relais n’est reçue du premier terminal (refus implicite), ou si un message de refus d’utiliser le service de relais a été reçu du premier terminal (refus explicite).
[0111] Dans un ou plusieurs modes de réalisation dans lesquels une pluralité de chemins est accessible au nœud relais pour acheminer des paquets entre le premier terminal Tl et le deuxième terminal T2, le message d’offre de service relais (par exemple, « PROXY_SERVICE_OFFER ») peut comprendre des données indiquant le support par le nœud relais d’un service de relais QUIC via des chemins multiples.
[0112] Ainsi, le service offert par le nœud relais peut comprendre un accès par le nœud relais à des chemins multiples pour supporter la communication entre le premier terminal et le deuxième terminal.
[0113] Par exemple, le nœud relais peut recevoir, en provenance du premier terminal, un message de la communication établie selon le protocole QUIC à destination du deuxième terminal, comprenant des données indiquant que le premier terminal accepte l’utilisation par le nœud relais de chemin multiples qui pourront être empruntés par les données échangées dans le cadre de la communication établie selon le protocole QUIC avec le deuxième terminal. Dans un mode de réalisation, le nœud relais peut en outre modifier le message QUIC pour y supprimer les données indiquant que le premier terminal accepte G utilisation par le nœud relais de chemin multiples pour la communication établie selon le protocole QUIC avec le deuxième terminal, puis transmettre le message modifié au deuxième terminal.
[0114] Dans un ou plusieurs modes de réalisation, le nœud relais peut être configuré pour inclure des données indiquant un support de service relais (par exemple l’information « PROXY_SERVICE_OFFER ») dans une pluralité de messages, voire dans tous les messages d’une communication QUIC à destination d’un terminal (Tl).
[0115] Dans un ou plusieurs modes de réalisation, un même relais peut être configuré pour inclure des données indiquant un support de service relais (par exemple l’information PROXY_SERVICE_OFFER) dans des messages destinés à Tl et T2.
[0116] Dans un ou plusieurs modes de réalisation, le nœud relais peut être configuré pour, sur réception de données indiquant une acceptation du premier terminal d’utiliser le service de relais (par exemple sur réception d’une option « PROXY_SERVICE_ACCEPT »), vérifier que cette réponse du premier terminal correspond à une offre émise par le nœud relais à ce terminal. Pour ce faire, dans un mode de réalisation, le nœud relais peut en outre être configuré pour déterminer si la valeur du champ portant un identifiant d’offre de service de relais (« Offer_ID »), reçu parmi les données indiquant une acceptation du premier terminal d’utiliser le service de relais, correspond à un identifiant d’offre stocké en mémoire, par exemple dans une table de sauvegarde des identifiants d’offres précédemment émises vers des terminaux.
[0117] Dans un ou plusieurs modes de réalisation, le nœud relais peut en outre être configuré pour rejeter (par exemple en l’ignorant) l’acceptation du premier terminal d’utiliser le service de relais si aucune offre n’est trouvée parmi celles précédemment émises vers des terminaux qui correspondent à l’identifiant reçu du premier terminal. Par exemple, dans le contexte spécifique et non limitatif d’utilisation du relais pour la gestion de chemins multiples pour la communication QUIC entre les deux terminaux, si aucune offre n’est trouvée, alors le nœud relais rejette ce message et, en conséquence, ne modifie pas sa ou ses politique(s) de gestion de chemins multiples.
[0118] Dans un ou plusieurs modes de réalisation, le nœud relais peut en outre être configuré pour, lorsqu’une offre est trouvée parmi celles précédemment émises vers des terminaux qui correspondent à l’identifiant reçu du premier terminal, extraire de données indiquant une acceptation du premier terminal d’utiliser le service de relais le jeton (« Token ») ou le « Challenge » ainsi que, le cas échéant, d’autres informations caractéristiques d’une offre de service relais, et les sauvegarder en mémoire, par exemple dans une table de connexions QUIC actives pour le premier terminal (par exemple appelée « PROXY_SERVICE_PEERS »). Dans un ou plusieurs modes de réalisation, le nœud relais peut en outre être configuré pour restreindre l’usage de la clé ou du jeton reçus à une seule adresse IP, un seul préfixe, ou à une seule paire constituée d’une adresse IP et d’un numéro de port. Dans ce cas, seules les requêtes émises sur une adresse particulière du relais seront associée à un jeton donné.
[0119] Ainsi, dans un ou plusieurs modes de réalisation, le message envoyé par le premier terminal pour indiquer au nœud relais une acceptation d’utiliser les services du nœud relais peut comprendre un algorithme de répartition de charge de trafic entre des chemins multiples destiné à être appliqué par le nœud relais. L’algorithme éventuellement sélectionné peut ainsi être utilisé par le nœud relais pour la gestion de la communication QUIC entre le premier terminal et le deuxième terminal, par exemple pour la gestion de cette communication via des chemins multiples disponibles. Grâce à ce procédé, un terminal peut négocier l’algorithme de distribution par connexion QUIC. Certaines connexions associées à un même terminal peuvent bénéficier du service de résilience en cas d’indisponibilité d’un chemin primaire, alors que d’autres connexions du même terminal peuvent bénéficier du service de « bonding ».
[0120] Dans un ou plusieurs modes de réalisation, le procédé proposé pourra comprendre une vérification de fiabilité du nœud relais par le premier terminal, effectuée avant d’accepter d’utiliser le service du nœud relais.
[0121] On note que le procédé selon l’invention est décrit ici en référence à un nœud relais localisé du côté du premier terminal Tl. Cette hypothèse n’est toutefois pas limitative. L’invention s’applique également à un nœud relais localisé du côté du deuxième terminal T2 : le nœud relais agit alors de la même façon à l’égard du terminal T2 que ce qui vient d’être décrit à l’égard du terminal Tl ; les rôles des terminaux Tl et T2 sont par ailleurs interchangés. L’invention peut également s’appliquer lorsqu’un nœud relais est localisé côté terminal Tl et un autre nœud relais est localisé côté terminal T2 : dans ce cas, une offre PROXY_SERVICE_OFFER est insérée par le nœud relais localisé du côté du terminal Tl dans un message adressé par le terminal T2 au terminal Tl transitant par ce nœud relais localisé côté terminal Tl, tandis qu’une offre PROXY_SERVICE_OFFER est insérée par le nœud relais localisé du côté du terminal T2 dans un message adressé par le terminal Tl au terminal T2 transitant par ce nœud relais localisé côté terminal T2.
[0122] En outre l’invention s’applique également à plusieurs nœuds relais déployés en cascade. [0123] Les terminaux, tels que les téléphones intelligents (« smartphone » en anglais) et les ordinateurs personnels sont désormais capables d’activer et d’exploiter plusieurs interfaces logiques liées à une ou plusieurs interfaces physiques. De tels terminaux sont dits « multi- interfaces » (« Multi-Interface », ou MIF en anglais).
[0124] Plusieurs adresses IP peuvent alors être attribuées à ces terminaux MIF pour qu’ils puissent se connecter à différents types de réseaux tels qu’un réseau fixe, un réseau mobile ou un réseau WLAN (Wireless LAN), de manière simultanée ou différée. Ces adresses IP peuvent appartenir à la même famille d’adresses ou à des familles d'adresses distinctes (IPv4, IPv6 ou les deux), avoir des durées de vie différentes, avoir des portées différentes (par exemple adresse IPv4 privée, adresse IPv6 unique de portée locale (« Unique Local Address », ou ULA en anglais), ou adresse IPv6 de portée globale (« Global Unicast Address », ou GUA en anglais)), et être affectées à la même interface réseau logique ou à différentes interfaces réseau logiques d’un même terminal.
[0125] La caractéristique « MIF » est volatile, car la capacité d’utiliser plusieurs interfaces dépend des conditions de raccordement au(x) réseau(x), de la localisation du dispositif, ou d’autres facteurs. Un terminal MIF peut notamment exploiter la pluralité d’interfaces dont il dispose durant l’établissement d’une connexion simple (c’est-à-dire, une connexion établie le long d’un chemin unique avec un correspondant donné), voire après l’établissement d’une connexion simple.
[0126] En outre, un terminal ne sait pas a priori s’il lui est possible d’utiliser plusieurs chemins distincts pour établir une communication avec un correspondant donné ; plus précisément, le terminal n’acquiert cette information (le cas échéant) qu’à l’issue d’une phase au cours de laquelle il tente d’établir une communication avec le correspondant en utilisant des chemins multiples.
[0127] Lorsqu’un terminal dispose de plusieurs interfaces capables de le raccorder à différents réseaux d’accès (par exemple, fixe, mobile, ou WLAN), il bénéficie alors d’un accès dit « hybride », parce qu’il combine différentes technologies de réseaux d’accès. Les offres de services concernant un terminal disposant d’un accès hybride reposent sur l’introduction dans le réseau de fonctions permettant d’agréger l’ensemble des connexions réseau d’un terminal (par exemple : WLAN et 3G, ADSL, WLAN et 4G, ou 4G et 5G). [0128] Dans le domaine des réseaux, les termes « agrégation de liens » désignent généralement un regroupement de plusieurs liens associés à autant d’interfaces (logiques) comme s'il s'agissait d'un seul lien associé à une seule interface, notamment dans le but d'accroître le débit au-delà des limites d'un seul lien, mais également d’appliquer les mêmes procédures d’exploitation à l’ensemble des liens ainsi agrégés (notion de « fate sharing » en anglais). Eventuellement, l’agrégation de liens permet aussi de faire en sorte que d’autres interfaces prennent le relais si un lien réseau tombe en panne (principe de redondance). L’agrégation de liens s’applique à tout type de trafic acheminé le long de ces liens, y compris du trafic IP.
[0129] L'agrégation de liens peut également être utilisée pour répartir le trafic sur plusieurs liens. Dans ce cas, la répartition de trafic entre des liens qui font l’objet d’un agrégat dépend de divers paramètres. La répartition de trafic dépend par exemple du type de trafic (par exemple trafic de type TCP ou trafic de type UDP), ou de la politique d'ingénierie de trafic (spécifiant par exemple un niveau requis de qualité de service (en anglais, « Quality of Service », ou « QoS »).
[0130] On note que divers modes d’agrégation peuvent être envisagés, parmi lesquels un mode dit « de repli » (consistant à utiliser des chemins secondaires en cas d’indisponibilité des chemins primaires), un mode dit « associatif » (consistant à utiliser les ressources associées à tout ou partie des chemins disponibles, les flux IP associés à une même application pouvant être répartis entre plusieurs chemins) et un mode dit « de confort » (similaire au mode associatif, si ce n’est que les flux d’une application donnée ne sont pas répartis entre plusieurs chemins, mais sont envoyés sur un seul chemin).
[0131] Ces différents modes ne sont pas mutuellement exclusifs, et ne sont pas spécifiques à un type particulier de trafic. Ainsi, ils peuvent être mis en place indépendamment de la nature du trafic qui sera acheminé le long des chemins agrégés selon l’un ou l’autre des différents modes.
[0132] Un terminal, disposant de plusieurs attachements réseau, peut avoir une ou plusieurs adresses IP affectées à chacune de ses interfaces physiques ou logiques. Il peut aussi ne disposer que d’une seule interface, auquel cas on pourra supposer qu’il est situé derrière une passerelle résidentielle connectée à un ou plusieurs réseaux et compatible avec un mécanisme d’agrégation de liens. Par ailleurs, une passerelle peut être configurée pour s’abstenir d’exploiter un mécanisme d’agrégation de liens réseau pour certains réseaux, ou dans certaines conditions de fonctionnement (par exemple, en cas de surcharge des concentrateurs de connexions réseau).
[0133] Des exemples de modes de réalisation dans le contexte non limitatif d’un service de relais pour rutilisation de chemins multiples pour une communication établie selon le protocole QUIC entre deux terminaux sont détaillés ci-après.
[0134] Dans un ou plusieurs modes de réalisation, dans le cas où un dispositif (dénoté relais ou « proxy »), situé sur le chemin des paquets QUIC échangés par deux terminaux Tl et T2, dispose de plusieurs chemins pour acheminer les paquets entre les deux terminaux Tl et T2, ce relais insère dans un message QUIC à destination du terminal Tl une information, par exemple appelée « PROXY_SERVICE_OFFER », indiquant le support du service de relais QUIC via des chemins multiples.
[0135] Le service relais peut permettre d’utiliser les ressources des chemins multiples disponibles pour améliorer les performances ou la résilience d’une connexion QUIC. Dans un ou plusieurs modes de réalisation, cette utilisation des ressources peut comprendre une réécriture de l’adresse source des paquets reçus du terminal Tl (respectivement, l’adresse destination des paquets à destination de Tl) pour pouvoir acheminer les paquets via certains chemins. La figure 2c illustre un exemple de problème rencontré pour l’acheminement des paquets sur des chemins multiples si l’adresse source n’est pas réécrite par un relais.
[0136] En référence à la figure 2c, on suppose que le terminal Tl (40a) est présent dans un LAN (42) connecté via un CPE (41) à trois réseaux (ADSL (43al), WLAN (43a2), et 4G (43a3)). Des adresses (ou des préfixes) distinctes (@IPpl, @IPp2, @IPp3) sont allouées par chacun de ces réseaux (43al, 43a2, 43a3) au CPE (41). Une adresse ou un préfixe (@IPtl) peuvent être délégués au terminal Tl (40a) depuis l’un des préfixes alloués par les réseaux (ADSL (43al), WLAN (43a2), et 4G (43a3)). Par exemple, l’adresse @IPtl pourra être une adresse extraite à partir d’un préfixe IPv6 de @IPpl. Dans ce cas, l’adresse source d’un paquet émis par le terminal Tl vers le terminal T2 est @IPtl. Si le nœud relais (41), embarqué dans le CPE, décide d’acheminer ce paquet tel quel via le réseau 4G, alors ce paquet sera bloqué par ce réseau pour des mesures de prévention d’usurpation d’adresse IP (en anglais « anti-spoofing »). Ces mesures consistent à vérifier que les machines connectées à un réseau ne peuvent émettre des données IP qu’avec une adresse source allouée par ce réseau. Dans ce cas, le nœud relais (41) ne pourra pas utiliser des chemins multiples, dont un chemin passant par le réseau 4G, pour la communication QUIC entre les terminaux Tl et T2.
[0137] Afin de résoudre ce problème, le nœud relais (41) peut réécrire l’adresse source du paquet avec l’adresse @IPp3, comme illustré sur la figure 2d. Le nœud relais (41) peut en effet décider d’ajouter un chemin à une connexion, retirer un chemin, changer d’adresse, changer de numéro de port, etc. Ces décisions sont normalement locales au relais et ne sont pas nécessairement prises en concertation avec les terminaux Tl et T2.
[0138] Dès lors, dans un ou plusieurs modes de réalisation des politiques de distribution de trafic peuvent être configurées sur le nœud relais, afin de lui permettre de répartir le trafic entre les différents réseaux disponibles. Selon le mode de réalisation, ces politiques pourront être configurées par un fournisseur de service et/ou par un utilisateur. Un exemple de politique serait de n’utiliser les ressources radio qu’en cas d’indisponibilité d’un réseau d’accès fixe ou lorsque les ressources disponibles du réseau d’accès principal (typiquement le réseau filaire) ne permettent plus d’écouler le trafic caractéristique d’une application donnée, etc.
[0139] Les politiques de distribution de trafic peuvent s’avérer critiques car une utilisation non adéquate des ressources disponibles peut induire une consommation rapide du quota disponible sur un lien d’accès donné, voire provoquer une augmentation sensible du montant de la facture à payer par l’utilisateur (dans le cas où le nœud relais est embarqué dans un CPE, par exemple).
[0140] La maîtrise d’une politique de distribution du trafic est également importante pour un opérateur car elle permet notamment de minimiser le risque de congestion de certains liens (par exemple, l’utilisation abusive d’une connexion cellulaire par un relais peut congestionner une cellule au détriment des terminaux mobiles mono-interface).
[0141] De retour sur la figure 2a, dans un ou plusieurs modes de réalisation, le nœud relais Pl i peut se charger de l’insertion de l’information « PROXY_SERVICE_OFFER ». Par exemple, le nœud relais peut sélectionner le/les message(s) QUIC reçu(s) de T2 et à destination de Tl associé(s) à une même connexion QUIC qui doit/doivent être utilisé(s) pour véhiculer l’information « PROXY_SERVICE_OFFER ». Pour ce faire, le nœud relais maintient dans un mode de réalisation une table de connexions QUIC actives avec gestion de l’état de chacune de ces connexions pour déterminer le nombre maximum d’insertions d’information par connexion QUIC, par identifiant de connexion, etc. Par exemple, un relais peut envoyer une offre « PROXY_SERVICE_OFFER » dans trois messages différents d’une connexion QUIC.
[0142] Dans un ou plusieurs modes de réalisation, le nœud relais peut être configuré pour, dans le cas d’un refus, explicite ou implicite, du (premier) terminal auquel il a adressé une offre de service pour utiliser des chemins multiples pour la communication QUIC de ce terminal, décider unilatéralement d’une politique d’acheminement de trafic à appliquer pour la communication QUIC entre le premier terminal et le deuxième terminal. Dans un mode de réalisation, le nœud relais peut être configuré pour, dans cette situation, désactiver les mécanismes d’exploitation des chemins multiples pour cette connexion. Ainsi, si le chemin initial utilisé pour l’établissement de la connexion QUIC n’est plus disponible, le nœud relais ne bascule pas le trafic vers un autre chemin, comme illustré sur les figures 2e et 2f.
[0143] De même que la figure 2a, la figure 2e montre un premier terminal Tl (30a) qui a établi une communication QUIC avec un deuxième terminal T2 (30b), ainsi qu’un nœud relais Pl i (31) situé sur le chemin de la communication QUIC, derrière un réseau NI (32) vis-à-vis du premier terminal Tl (30a), et derrière un sous-réseau Ni l (33al) connecté au réseau Internet (33b) vis-à-vis du deuxième terminal T2 (30b).
[0144] Comme illustré sur la figure 2e, dans un ou plusieurs modes de réalisation, le premier terminal Tl (30a) peut, dans le cadre d’un échange de messages QUIC avec le second terminal T2 (30b), transmettre au deuxième terminal T2 (30b) un message QUIC (Ml), puis recevoir un message QUIC (M2a) issu d’un message QUIC émis par le deuxième terminal et dans lequel le nœud relais Pl i (31) aura inséré des données d’offre de service relais (PROXY_SERVICE_OFFER) d’utilisation de chemins multiples gérés par le nœud relais pour la communication QUIC entre le premier (Tl) et le deuxième (T2) terminal.
[0145] Le premier terminal Tl (30a) peut refuser l’offre de service relais d’utilisation de chemins multiples par l’insertion dans un message QUIC (M3a) destiné au deuxième terminal T2 (30b) de données de refus d’offre de service relais (PROXY_SERVICE_DISCARD), qui seront extraites du message (M3a) par le nœud relais Pl i (31) sur réception du message. Le nœud relais Pl i (M3a) transmettra alors le message QUIC (M3), en provenance du premier terminal Tl (30a), au deuxième terminal T2 (30b), après avoir extrait (et retiré) du message reçu (M3a) la réponse du premier terminal Tl (30a) à son offre de service relais d’utilisation de chemins multiples.
[0146] Sur réception d’un refus d’utiliser un service relais d’utilisation de chemins multiples gérés par le nœud relais pour la communication QUIC entre le premier (Tl) et le deuxième (T2) terminal, le nœud relais pourra désactiver une option d’utilisation de chemin multiples pour la communication QUIC entre le premier (Tl) et le deuxième (T2) terminal, de sorte qu’en cas d’échec de transmission de paquets QUIC sur le chemin unique utilisé par les premier (Tl) et deuxième (T2) terminaux, un nouveau message QUIC (M4) émis par le premier terminal Tl (30a) vers le deuxième terminal T2 (30b), parvenant au nœud relais Pl i (31), pourra ne pas être transmis avec succès entre le nœud relais Pl i (31) et le deuxième terminal T2 (30b), comme illustré sur la figure 2f.
[0147] Les modes de réalisation du procédé proposé décrits ci-après se rapportent au point de vue du premier terminal (terminal local au nœud relais).
[0148] A nouveau en référence à la figure 2a, dans un ou plusieurs modes de réalisation, le premier terminal (terminal local) (30a) peut être configuré pour recevoir un message (M2a) de la communication établie selon le protocole QUIC, et détecter dans le message reçu la présence de données indiquant le support par le nœud relais (31) d’un service de relais QUIC.
[0149] Comme décrit ci-dessus, les données indiquant le support par le nœud relais Pl i (31) d’un service de relais QUIC reçues par le premier terminal (30a) peuvent être, dans un ou plusieurs modes de réalisation, comprises dans une option UDP. De même, dans un ou plusieurs modes de réalisation, ces données peuvent comprendre des premières données d’identification du nœud relais (« Relay_ID »), ainsi qu’ éventuellement, en fonction du mode de réalisation, des premières données d’identification d’offre de service (« Offer_ID »), des premières données d’accès au nœud relais (« Locator(s) »), et/ou des données de description de service (« Service Description »). Par exemple, le message PROXY_SERVICE_OFFER peut comprendre une option UDP comprenant un champ identifiant du nœud relais (« Relay_ID »), et un champ identifiant d’offre de service (« Offer_ID »), un champ de premier localisateur du nœud relais (« Locator(s) »), et/ou un champ de données de description de service (« Service Description »). [0150] Dans un ou plusieurs modes de réalisation, le premier terminal (30a) (terminal local) peut en outre être configuré pour, sur réception des données indiquant le support par le nœud relais Pl i (31) d’un service de relais QUIC, déterminer si l’utilisation du service de relais proposé par le nœud relais Pl i (31) est acceptée ou non (ou, en variante, si l’utilisation est refusée ou non), et dans le cas où l’utilisation est acceptée (ou, en variante, n’est pas refusée), émettre à destination du deuxième terminal (terminal distant), un message de la communication établie selon le protocole QUIC comprenant des données indiquant une acceptation du premier terminal d’utiliser le service de relais QUIC, et dans le cas où l’utilisation est acceptée (ou, en variante, est refusée), émettre à destination du deuxième terminal (terminal distant), un message de la communication établie selon le protocole QUIC comprenant des données indiquant un refus du premier terminal d’utiliser le service de relais QUIC.
[0151] Dans un ou plusieurs modes de réalisation, les données indiquant une acceptation du premier terminal d’utiliser le service de relais QUIC peuvent comprendre des deuxièmes données d’identification du nœud relais qui correspondent aux premières données d’identification du nœud relais reçues avec les données indiquant le support par le nœud relais d’un service de relais.
[0152] Dans un ou plusieurs modes de réalisation, le premier terminal (30a) peut en outre être configuré pour, dans le cas où l’utilisation du relais Pl i (31) est acceptée (ou, en variante, n’est pas refusée) générer (par exemple aléatoirement) un jeton et éventuellement un « Challenge », et inclure ce jeton et le cas échéant ce « Challenge » dans les données indiquant une acceptation du premier terminal d’utiliser le service de relais QUIC émises vers le deuxième terminal.
[0153] Dans un ou plusieurs modes de réalisation, le premier terminal (30a) peut en outre être configuré pour, dans le cas où l’utilisation du relais Pl i (31) est acceptée (ou, en variante, n’est pas refusée) inclure dans les données indiquant une acceptation du premier terminal d’utiliser le service de relais QUIC émises vers le deuxième terminal des deuxièmes données d’identification d’offre de service correspondant aux premières données d’identification d’offre de service reçues avec les données indiquant le support par le nœud relais d’un service de relais.
[0154] Dans un ou plusieurs modes de réalisation, les données indiquant une acceptation du premier terminal d’utiliser le service de relais QUIC et les données identifiant un nœud relais utilisable pour la communication avec le premier terminal peuvent être comprises dans un même message envoyé sur la connexion établie selon le protocole QUIC et émis par le premier terminal à destination du deuxième terminal.
[0155] Dans un ou plusieurs modes de réalisation dans lesquels le message d’offre de service relais (par exemple l’option UDP « PROXY_SERVICE_OFFER » comme décrit ci-dessus) comprend des données indiquant le support par le nœud relais d’un service de relais QUIC via des chemins multiples, les données indiquant une acceptation du premier terminal d’utiliser le service de relais QUIC peuvent comprendre en outre des données de description de service indiquant un algorithme de répartition de charge de trafic choisi par le premier terminal pour la communication établie selon le protocole QUIC sur des chemins multiples avec le deuxième terminal.
[0156] Ainsi, dans un ou plusieurs modes de réalisation, sur réception d’un message QUIC par un terminal (ou par un nœud relais du chemin), ce dernier vérifie si une ou plusieurs options PROXY_SERVICE_OFFER (ou PROXY_SERVICE_ACCEPT/ PROXY_SERVICE_DISCARD pour un nœud relais) sont présentes dans le message reçu.
[0157] Dans un mode de réalisation, cette vérification peut comprendre une détection de présence d’informations supplémentaires, par exemple par comparaison des champs « IP Length » de l’en-tête IP et « UDP Length » de l’en-tête UDP. La ou les options PROXY_SERVICE_OFFER peuvent ainsi être extraites du message, et le terminal peut ensuite procéder à des vérifications d’intégrité sur cette/ces options. Dans un mode de réalisation, le terminal ignore l’option PROXY_SERVICE_OFFER si une anomalie est alors détectée.
[0158] Dans un ou plusieurs modes de réalisation, le terminal peut être configuré pour déterminer s’il peut faire confiance au nœud relais identifié dans les données reçues indiquant le support d’un service de relais. Par exemple, dans le cas où le nœud relais ayant offert un support de service de relais est mis en œuvre au sein d’un équipement CPE auquel le terminal est connecté (par exemple par le biais d’un réseau LAN ou d’un réseau WLAN) comme illustré sur les figures 2c et 2d, le terminal peut déterminer qu’il peut faire confiance au CPE auquel il est raccordé sur la base de l’adresse IP du CPE. Dans un mode de réalisation, le terminal peut être configuré avec une liste de relais de confiance déployés par le fournisseur de connectivité IP, auquel cas la vérification de confiance peut se faire sur la base des données d’identification de relais reçues avec les données indiquant le support d’un service de relais (par exemple, un identifiant de relais (« Relay_ID »)). D’autres mécanismes de vérification de confiance, alternatifs ou complémentaires à ceux décrits ci-dessus, peuvent être mis en place par le terminal dans le cadre des modes de réalisation du procédé proposé. Dans un mode de réalisation, l’option PROXY_SERVICE_OFFER est ignorée si la vérification conclut que le nœud relais n’est pas un élément de confiance.
[0159] Dans un ou plusieurs modes de réalisation, si le terminal ne souhaite pas utiliser les ressources du relais pour la communication QUIC en cours, le terminal inclut une option UDP PROXY_SERVICE_DISCARD dans un message envoyé au terminal distant.
[0160] En fonction du mode de réalisation, cette option peut inclure un ou plusieurs des éléments suivants :
[0161] « Relay_ID » : des données d’identification du nœud relais correspondant à celles éventuellement reçues dans les données indiquant le support par le nœud relais d’un service de relais. Ces données d’identification du nœud relais peuvent par exemple correspondre à une copie du champ correspondant inclus dans les données indiquant le support par le nœud relais d’un service de relais (par exemple dans l’option UDP PROXY_SERVICE_OFFER) .
[0162] « Offer_ID » : des données d’identification d’offre de service correspondant à celles éventuellement reçues dans les données indiquant le support par le nœud relais d’un service de relais. Ces données d’identification d’offre de service peuvent par exemple correspondre à une copie du champ correspondant et inclus dans les données indiquant le support par le nœud relais d’un service de relais (par exemple dans l’option UDP PROXY_SERVICE_OFFER) .
[0163] Dans un ou plusieurs modes de réalisation, si le terminal accepte d’utiliser les ressources du relais pour la communication QUIC en cours, le terminal inclut une option UDP PROXY_SERVICE_ACCEPT dans un message à destination du terminal distant.
[0164] En fonction du mode de réalisation, cette option peut inclure un jeton (« Token »), c’est-à-dire une clé générée, par exemple aléatoirement, par le terminal, ainsi qu’un ou plusieurs des éléments suivants :
[0165] « Relay_ID » : des données d’identification du nœud relais correspondant à celles éventuellement reçues dans les données indiquant le support par le nœud relais d’un service de relais. Ces données d’identification du nœud relais peuvent par exemple correspondre à une copie du champ correspondant inclus dans les données indiquant le support par le nœud relais d’un service de relais (par exemple dans l’option UDP PROXY_SERVICE_OFFER) .
[0166] « Offer_ID » : des données d’identification d’offre de service correspondant à celles éventuellement reçues dans les données indiquant le support par le nœud relais d’un service de relais. Ces données d’identification d’offre de service peuvent par exemple correspondre à une copie du champ correspondant inclus dans les données indiquant le support par le nœud relais d’un service de relais (par exemple dans l’option UDP PROXY_SERVICE_OFFER) .
[0167] « Service Description » : des données indiquant un algorithme de répartition de charge de trafic choisi par le terminal pour cette communication QUIC. Dans un mode de réalisation, si aucun choix n’est retourné dans la réponse du terminal à l’offre de service de relais, le nœud relais peut être configuré pour déterminer d’utiliser une configuration par défaut pour cette connexion QUIC.
[0168] « Challenge » : Une clé générée aléatoirement par le terminal.
[0169] La figure 3a illustre un exemple de mise en œuvre du procédé proposé selon un ou plusieurs modes de réalisation.
[0170] Un premier terminal Tl (50a) et un deuxième terminal T2 (50b) peuvent être configurés pour établir une communication QUIC (en établissant une communication selon les modalités du protocole QUIC) et échanger (51a) des messages de cette communication QUIC.
[0171] Comme décrit ci-dessus, le premier terminal Tl (50a) peut en outre être configuré pour découvrir (51b) un nœud relais (Pl i) situé sur le chemin de la communication qui soit apte à fournir un service pour la communication. Par exemple, le premier terminal Tl (50a) peut être configuré pour, sur réception d’une offre de service relais pour la communication QUIC entre le premier terminal Tl (50a) et le deuxième terminal T2 (50b) en provenance d’un nœud relais (Pl i) situé sur le chemin de la communication QUIC entre le premier terminal Tl (50a) et le deuxième terminal T2 (50b), déterminer si cette offre est acceptée ou non. [0172] Dans un ou plusieurs modes de réalisation, dans le cas où le premier terminal Tl (50a) accepte d’utiliser le service du nœud relais, le premier terminal Tl (50a) peut émettre vers le deuxième terminal T2 (50b), lors d’une phase d’établissement ou au cours de la communication (51a) entre le premier terminal (50a) et le deuxième terminal (50b), un message d’information de relais chiffré comprenant des données identifiant le nœud relais (PI 1) et un jeton destiné à être fourni par le nœud relais (PI 1) au deuxième terminal (50b).
[0173] Dans le cas où cette offre est acceptée, le premier terminal Tl (50a) peut être configuré pour proposer au deuxième terminal T2 (50b) d’utiliser le nœud relais en support de la communication QUIC entre les deux terminaux (50a, 50b).
[0174] Dans un ou plusieurs modes de réalisation, le premier terminal peut émettre (52), vers le deuxième terminal, un message d’information de relais (message « PATH_PROBE_TARGET » sur la figure 4a) de la communication QUIC établie entre le premier terminal et le deuxième terminal. Le message d’information de relais peut comprendre des données identifiant un nœud relais utilisable pour la communication avec le premier terminal.
[0175] Ainsi, le deuxième terminal peut recevoir, en provenance du premier terminal, un message d’information de relais chiffré comprenant un jeton et des données identifiant un nœud relais entre le premier terminal et le deuxième terminal apte à fournir un service pour la communication entre le premier terminal et le deuxième terminal.
[0176] Par exemple, en référence à la figure 3a, le deuxième terminal T2 (50b) peut recevoir, en provenance du premier terminal, un message d’information de relais (message « PATH_PROBE_TARGET » sur la figure 3a) de la communication QUIC établie entre le premier terminal et le deuxième terminal, le message d’information de relais comprenant des données identifiant un nœud relais utilisable pour la communication avec le premier terminal.
[0177] Le message d’information de relais permet avantageusement de fournir au terminal distant, dans le cadre d’une communication QUIC avec ce terminal distant, des données concernant l’utilisation d’un nœud relais pour la communication QUIC.
[0178] Par exemple, le premier terminal peut envoyer au deuxième terminal un message spécifique de la communication QUIC, message qui sera interprété par le deuxième terminal comme indiquant que le premier terminal propose d’utiliser un ou plusieurs services relais pour la communication QUIC entre les deux terminaux.
[0179] Dans un ou plusieurs modes de réalisation, la communication QUIC entre les deux terminaux peut être une communication à chemins multiples, ou potentiellement le devenir par le biais du service de relais. Dans les modes de réalisation où une pluralité de chemins est accessible au nœud relais pour la communication QUIC entre le premier terminal et le deuxième terminal, le message d’information de relais peut être interprété par le deuxième terminal comme une offre d’utilisation de chemins multiples, par le biais du nœud relais, pour la communication QUIC avec le premier terminal. Le message d’information de relais peut ainsi comprendre des données identifiant un nœud relais ayant accès à une pluralité de chemins pour la communication entre le premier terminal et le deuxième terminal, comme illustré sur la figure 2d.
[0180] Dans un ou plusieurs modes de réalisation, les données identifiant le nœud relais peuvent comprendre des données d’identification du nœud relais, comme par exemple un identifiant du nœud relais alloué par le premier terminal, ou un identifiant du nœud relais communiqué par le nœud relais au premier terminal. Les données identifiant le nœud relais peuvent en outre comprendre des données d’accès au nœud relais, comme par exemple une adresse du nœud relais (par exemple une adresse IP, éventuellement combinée à un numéro de port). Ces données d’accès au nœud relais peuvent correspondre à des données d’accès communiquées par le nœud relais au premier terminal. Les données identifiant le nœud relais peuvent en outre comprendre un ou plusieurs identifiants de connexion QUIC, par exemple sous forme d’une liste d’un ou plusieurs identifiant de connexion QUIC. Enfin, les données identifiant le nœud relais peuvent en outre comprendre un « Challenge » et un jeton identiques à ceux communiqués par le premier terminal au nœud relais.
[0181] Sur réception du message d’information de relais, le deuxième terminal peut refuser d’utiliser les services du relais identifié dans le message d’information de relais, de manière implicite ou explicite selon le mode de réalisation choisi.
[0182] Le refus explicite peut être communiqué au premier terminal par l’émission d’un message de refus d’utiliser le nœud relais pour la communication avec le premier terminal. Dans un ou plusieurs modes de réalisation, le message de refus est un message QUIC (par exemple introduit sous le nom « PATH_PROBE_REJECT ») informant le premier terminal du refus du deuxième terminal d’utiliser le nœud relais. Ce message de refus peut, dans un mode de réalisation, comprendre un identifiant du nœud relais afin de distinguer le nœud relais objet du message en cas d’utilisation possible de plusieurs nœud relais, par exemple correspondant à un identifiant de nœud relais reçu par le deuxième terminal dans le message d’information de relais.
[0183] Dans le cas d’un refus explicite communiqué au premier terminal, le premier terminal peut recevoir, en provenance du deuxième terminal, un message de la communication établie selon le protocole QUIC de refus d’utiliser un relais comprenant des données indiquant un refus par le deuxième terminal d’utiliser le nœud relais pour la communication avec le premier terminal. Dans un mode de réalisation, les données indiquant un refus d’utiliser le nœud relais peuvent comprendre des données d’identification du nœud relais correspondant à des données d’identification du nœud relais transmises par le premier terminal dans le message d’information de relais.
[0184] A l’inverse, sur réception du message d’information de relais, le deuxième terminal peut accepter d’utiliser les services du relais identifié dans le message d’information de relais, de manière implicite ou explicite selon le mode de réalisation choisi.
[0185] L’acceptation explicite peut être communiquée au premier terminal par l’émission d’un message d’acceptation d’utiliser le nœud relais pour la communication avec le premier terminal. Dans un ou plusieurs modes de réalisation, le message d’acceptation est un message QUIC (par exemple appelé « PATH_PROBE_ACCEPT ») communiquant au premier terminal l’acceptation du deuxième terminal d’utiliser le nœud relais. Ce message d’acceptation peut, dans un mode de réalisation, comprendre un identifiant du nœud relais afin de distinguer le nœud relais objet du message en cas d’utilisation possible de plusieurs nœud relais, par exemple correspondant à un identifiant de nœud relais reçu par le deuxième terminal dans le message d’information de relais.
[0186] Dans le cas d’une acceptation explicite communiquée au premier terminal, le premier terminal peut recevoir, en provenance du deuxième terminal, un message de la communication établie selon le protocole QUIC d’acceptation d’utiliser un relais comprenant des données indiquant une acceptation par le deuxième terminal d’utiliser le nœud relais pour la communication avec le premier terminal. Dans un mode de réalisation, les données indiquant une acceptation d’utiliser le nœud relais peuvent comprendre des données d’identification du nœud relais correspondant à des données d’identification du nœud relais transmises par le premier terminal dans le message d’information de relais. [0187] Ainsi, dans un ou plusieurs modes de réalisation, le premier terminal (Tl) (ou terminal local) communique l’identité du relais dans un message QUIC éventuellement chiffré au deuxième terminal (ou terminal distant) (T2), par exemple à l’aide d’une nouvelle trame QUIC d’information de relais, par exemple appelée « PATH_PROBE_TARGET », dont une structure possible est illustrée par la figure 3b.
[0188] Comme illustré sur la figure 3b, la nouvelle trame QUIC (60) proposée pour l’information de relais peut comprendre, selon les modes de réalisation, un ou plusieurs des champs suivants :
[0189] Un premier champ (60a) appelé « Target_Id », qui porte un identifiant du relais, par exemple alloué par le terminal émetteur du message d’information de relais pour identifier le nœud relais objet du message.
[0190] Un deuxième champ (60b) appelé « Locator(s) », qui porte un ou plusieurs localisateur(s) pour joindre le nœud relais. En fonction du mode de réalisation, un localisateur peut par exemple être une adresse IPv4, une adresse IPv6 ou une adresse IP et un numéro de port. Dans un mode de réalisation, ce champ correspond à une copie du champ « Locator(s) » de l’option UDP PROXY_SERVICE_OFFER transmise par le nœud relais au premier terminal.
[0191] Un troisième champ (60c) appelé « Connection_ID(s) », qui décrit une liste contenant un ou plusieurs identifiants de connexions dont le chemin implique le nœud relais.
[0192] Un quatrième champ (60d) appelé « Token » (jeton), qui décrit une clé identique à celle communiquée au nœud relais dans un message d’acceptation d’utilisation de relais transmis par le premier terminal au nœud relais.
[0193] Un cinquième champ (60e) appelé « Challenge », qui décrit un défi (« Challenge ») identique à celui communiquée au nœud relais dans un message d’acceptation d’utilisation de relais transmis par le premier terminal au nœud relais.
[0194] Le terminal peut aussi inclure l’identité du relais lors de la création de nouveaux identifiants de connexions. Pour ce faire, la trame NEW_CONNECTION_ID est modifiée pour associer un relais avec un identifiant de connexion. La trame est modifiée pour renseigner l’identifiant (ou les identifiants) de nœuds relais aptes à être impliqués lorsque des nouveaux identifiants de connexions sont utilisés. [0195] La figure 2g montre un exemple de trame NEW_CONNECTION_ID modifiée pour associer un relais avec un identifiant de connexion.
[0196] Dans un mode de réalisation, l’option PROXY_SERVICE_ACCEPT peut être incluse dans le même message QUIC que celui qui transporte la trame P ATH_PROB E_T ARGET .
[0197] En référence à la figure 3a, dans un ou plusieurs modes de réalisation, le deuxième terminal T2 (50b) peut être configuré pour, sur réception du message d’information de relais et des données identifiant le nœud relais, sauvegarder dans une table (53, table « MP_PEER_TBL »), par exemple stockée dans la mémoire dudit terminal, les données identifiant le nœud relais reçues. Lorsque les données identifiant le nœud relais comprennent de données d’identification du nœud relais, des données d’accès au nœud relais dans le réseau de communication associé, une première liste d’ identifiants de connexions dont le chemin implique le nœud relais, un « Challenge », et un jeton (« Token »), la table MP_PEER_TBL peut être configurée pour stocker les données d’identification du nœud relais en association avec les données d’accès au nœud relais dans le réseau de communication associé, une deuxième liste d’ identifiants de connexions associées établie sur la base de la première liste d’ identifiants de connexions dont le chemin implique le nœud relais, et avec le jeton.
[0198] Par exemple, dans un ou plusieurs modes de réalisation, le deuxième terminal T2 (50b) peut être configuré pour, sur réception d’une trame QUIC d’information de relais (par ex. « PATH_PROBE_T ARGET »), procéder aux vérifications d’intégrité spécifiées pour le protocole QUIC utilisé, puis extraire le contenu de la trame PATH_PROBE_TARGET. Il peut en outre être configuré pour sauvegarder dans une table (par ex. « MP_PEER_TBL ») l’identité du relais, les localisateurs associés, le « Challenge », et la clé de sécurité (jeton ou « Token ») ainsi qu’une liste des identifiants de connexions associés.
[0199] Ainsi, dans un ou plusieurs modes de réalisation, le deuxième terminal peut être configuré pour mémoriser pour la communication le jeton reçu et un premier quadruplet comprenant une adresse et un numéro de port source, et une adresse et un numéro de port destination du message d’information de relais, et sur détection, dans un message subséquent de la communication en provenance du premier terminal, d’une adresse source différente de l’adresse source du premier quadruplet, vérifier auprès du nœud relais si le message subséquent a transité par le nœud relais, et le cas échéant, mémoriser pour la communication, un deuxième quadruplet comprenant l’adresse et le numéro de port source et l’adresse et le numéro de port destination du message subséquent. Dans un ou plusieurs modes de réalisation, le deuxième quadruplet peut être mémorisé tout en conservant le premier quadruplet.
[0200] Cette liste est mise à jour avec des trames modifiées NEW_CONNECTION_ID reçues du premier terminal, comme illustré sur la figure 2g.
[0201] On décrit ci-après des modes de réalisation du procédé proposé dans le contexte non limitatif dans lequel le service relais est utilisé pour la mise en œuvre de chemins multiples pour une communication établie selon les modalités du protocole QUIC entre un premier terminal et un deuxième terminal.
[0202] Dans un ou plusieurs modes de réalisation dans lesquels un nœud relais est utilisé pour la mise en œuvre et la gestion de chemins multiples pour une communication établie selon un protocole QUIC entre deux terminaux, le nœud relais peut envoyer un message d’offre de service relais pour la gestion de chemins multiples pour la communication QUIC (par exemple sous forme d’une option UDP (par exemple « PROXY_SERVICE_OFFER ») insérée dans une trame QUIC transmise par un deuxième terminal (dit « distant ») à un premier terminal (dit « local »)) au terminal local, et recevoir en retour des données d’acceptation du terminal local (par exemple une option UDP (par exemple « PROXY_SERVICE_ACCEPT ») insérée dans une trame QUIC transmise au terminal distant) pour G utilisation du relais pour la gestion de chemins multiples pour la communication QUIC entre le terminal local et le terminal distant, les données d’acceptation comprenant des données de validation (par exemple un jeton ou une clé numérique). Sur réception des données d’acceptation, le nœud relais peut en extraire les données de validation, et sauvegarder celles-ci dans une mémoire, par exemple sous forme d’une table (par exemple appelée « PROXY_SERVICE_PEERS ») de connexions actives pour le terminal local.
[0203] Le terminal local peut ensuite transmettre au terminal distant une trame QUIC d’information concernant le nœud relais (par exemple « PATH_PROBE_TARGET ») comprenant des données d’information sur le nœud relais, les données d’information comprenant des données d’identification du nœud relais, des données d’accès au nœud relais, et les données d’acceptation (par exemple le « Challenge » ou le jeton) précédemment communiquées au nœud relais. Sur réception de la trame QUIC d’information concernant le nœud relais, le terminal distant peut consigner dans une mémoire les données d’information sur le nœud relais reçues du terminal local, par exemple sous forme d’une table (par exemple appelée « MP_PEER_TABLE »).
[0204] Dans un ou plusieurs modes de réalisation, les opérations de gestion de chemins multiples et de vérification d’adresses ne se feront pas entre les deux terminaux en direct pour ces identifiants de connexion mais entre le terminal et le nœud relais selon les informations consignées dans la table des connexions actives maintenue par le nœud relais.
[0205] Dans un ou plusieurs modes de réalisation, en cas de détection d’un nouveau chemin (par ex. un message QUIC comportant un quadruplet {adresse source, port source, adresse destination, port destination}), le terminal distant consulte sa table
(MP_PEER_TABLE) pour récupérer l’identité et le(s) localisateur(s) du relais associé. Ensuite, le terminal distant envoie un message PATH_PROBE_REQUEST (Request_ID, [Peer ID, Connection_ID, External IP address, Extemal port number, Challenge..]) dont l’adresse de destination est un localisateur du relais. La trame QUIC
PATH_PROBE_REQUEST comprend l’identifiant de requête « Request_ID », et optionnellement un ou plusieurs des paramètres suivants : « Peer ID », « Connection_ID », « External IP address », « External port number », et un défi (« Challenge ») extrait de la table MP_PEER_TABLE. Le champ « Request_ID » indique un identifiant de requête PATH_PROBE_REQUEST. Ce champ est utilisé pour corréler une requête et la réponse associée. Le champ « Peer ID » est un champ optionnel qui indique l’identifiant du relais (Relay_ID) tel que communiqué au préalable par un terminal distant. Le champ
« Connection-ID » est un champ optionnel qui indique l’identifiant de la connexion relayée par un relais. Le champ « Extemal IP address » est un champ optionnel qui renseigne l’adresse IP source des messages reçus du terminal en direct (i.e., sans relais). Le champ « External port number » est un champ optionnel qui renseigne le numéro de port source des messages reçus du terminal en direct.
[0206] Le défi inclus par le terminal distant dans une requête PATH_PROBE_REQUEST () est identique à celui communiqué au préalable par le terminal source. En variante, le défi est composé d’un ou plusieurs paramètres tels que l’adresse IP externe et « Challenge » ou l’adresse IP externe et « Connection_ID ». Le défi inclus peut ainsi être structurée selon la forme suivante « paramètrel% paramètre2%... ». « % » est utilisé comme séparateur. Dans la suite, le terme « défi » est utilisé en référence au champ « Challenge » ou à celui de la variante.
[0207] Dans un ou plusieurs modes de réalisation, à réception de la trame PATH_PROBE_REQUEST par le nœud relais, ce dernier vérifie si une entrée associée à cette requête est présente dans sa table de connexions actives pour le terminal local (PROXY_SERVICE_PEERS ) .
[0208] Dans un ou plusieurs modes de réalisation, si une entrée est présente, le nœud relais extrait les données de validation associées, par exemple le jeton (« Token ») associé, et l’inclut dans un message PATH_PROBE_REPLY renvoyé au terminal distant, ainsi que l’identifiant de requête (« Request_ID ») extrait de la trame PATH_PROBE_REQUEST reçue. La trame QUIC PATH_PROBE_REPLY comprend l’identifiant de requête « Request_ID », et optionnellement un ou plusieurs des paramètres suivants : « Code » et « Token ». Le champ « Code » indique le résultat de la requête.
[0209] Dans un ou plusieurs modes de réalisation, si aucune entrée n’a été trouvée, le nœud relais peut répondre avec un message d’erreur PATH_PROBE_REPLY (Error_Code=Not Found). Le nœud relais peut également ignorer la requête.
[0210] Dans un ou plusieurs modes de réalisation, sur réception du message PATH_PROBE_REPLY, le terminal distant compare le jeton (« Token ») reçu dans la réponse avec celui maintenu dans sa table MP_PEER_TABLE. Le chemin n’est pas validé en cas de détection d’anomalie lors de l’opération de vérification du jeton.
[0211] Pour tout chemin validé, le terminal distant peut alors utiliser les ressources associées et ne procède pas à la migration de connexion.
[0212] Ainsi, dans un ou plusieurs modes de réalisation, le procédé proposé peut en outre comprendre, lors de l’établissement de la communication entre le premier terminal et le deuxième terminal ou à tout autre moment de la communication, indiquer au premier terminal que le deuxième terminal supporte une extension du protocole QUIC qui permet l’établissement de communications selon le protocole QUIC sur des chemins multiples, même si un seul chemin est disponible localement au niveau du deuxième terminal.
[0213] Dans un ou plusieurs modes de réalisation, la vérification effectuée par le deuxième terminal peut comprendre : envoyer un message de demande de vérification au nœud relais comprenant l’adresse source du deuxième quadruplet ou un défi, recevoir un message de réponse du nœud relais comprenant un jeton, et vérifier la coïncidence entre le jeton reçu du nœud relais et le jeton mémorisé.
[0214] Dans un ou plusieurs modes de réalisation, le deuxième terminal peut en outre être configuré pour, si les deux jetons coïncident, utiliser le deuxième quadruplet pour l’envoi de messages chiffrés au premier terminal.
[0215] L’utilisation de chemins multiples selon le procédé proposé est illustré dans un exemple de mise en œuvre sur les figure 4a et 4b.
[0216] La figure 4a montre un exemple d’établissement de communication selon le protocole QUIC entre un terminal local (Tl) et un terminal distant (T2), via un relais (Pl i) selon un chemin de communication initial (CCi), tandis que la figure 5b montre un exemple d’établissement de communication selon le protocole QUIC via des chemins multiples.
[0217] En référence à la figure 4a, le nœud relais (Pl i) utilise une adresse (ou un préfixe) (@IPpl l) alloué par le sous-réseau (Ni l) par lequel passe le chemin de communication initial. En référence à la figure 4b, le nœud relais (Pl i) utilise deux adresses (ou préfixes) (@IPpl l et @IPpli) respectivement alloués par les sous-réseaux (Ni l) et (Nli) par lesquels passent respectivement le chemin de communication initial (CCi) et le chemin de communication secondaire (CCs). L’exemple illustré sur la figure 4b ne fait ainsi pas intervenir le terminal local (Tl) dans la mise en œuvre de la communication QUIC à chemins multiples.
[0218] L’homme du métier pourra comprendre que l’exemple illustré sur la figure 4b n’est pas limitatif, en ce que le procédé proposé pour la mise en œuvre de chemins multiples pour une communication QUIC en utilisant un nœud relais n’est pas limité à deux chemins, ou à l’utilisation d’un relais unique, mais qu’il peut être utilisé pour la mise en œuvre de deux ou plus chemins multiples pour une communication QUIC entre deux terminaux en utilisant un ou plusieurs nœuds relais.
[0219] La figure 5a illustre un exemple d’architecture d’un terminal pour la mise en œuvre du procédé proposé.
[0220] En référence à la figure 5a, 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. [0221] 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 filaire ou sans-fil), par exemple de type WLAN, Ethernet, UMTS, LTE, ou LTE-A.
[0222] Le contrôleur 101 est configuré pour piloter le module de gestion de communications 104 et rinterface de communication 102 pour la mise en œuvre d’un ou de plusieurs modes de réalisation du procédé proposé.
[0223] 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). Dans un ou plusieurs modes de réalisation, le module de gestion de communications 104 est configuré pour émettre, vers un autre terminal, un message d’information de relais d’une communication établie selon un QUIC avec l’autre terminal, le message d’information de relais comprenant des données identifiant un nœud relais utilisable pour la communication avec le premier terminal, et pour recevoir, en provenance d’un autre terminal, un tel message d’information de relais.
[0224] 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. [0225] 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.
[0226] La figure 5b illustre un exemple d’architecture d’un nœud relais pour la mise en œuvre du procédé proposé.
[0227] En référence à la figure 5b, 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 relais QUIC 204.
[0228] 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, UMTS, LTE, LTE-A.
[0229] Le contrôleur 201 est configuré pour piloter le module de service de relais 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é.
[0230] Le module de service de relais 204 est configuré pour la mise en œuvre du procédé proposé par un nœud relais. En particulier, le module de service de relais 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 relais.
[0231] 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 relais 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.
[0232] 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 LPGA (Lield Programmable Gâte Array). De même, le module de service de relais 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 LPGA.
Application industrielle
[0233] 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.
[0234] Bien que décrits à travers un certain nombre d’exemples de réalisation détaillés, le procédé 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 équipements 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 gestion d’une communication établie selon le protocole QUIC entre un premier terminal et un deuxième terminal connectés via un réseau de communication, le procédé comprenant, au premier terminal:
découvrir au moins un nœud relais entre le premier terminal et le deuxième terminal, ledit nœud relais étant apte à fournir au moins un service pour ladite communication ; et si le premier terminal accepte ledit service, émettre vers le deuxième terminal, lors d’une phase d’établissement ou au cours de ladite communication, un message d’information de relais chiffré comprenant des données identifiant ledit au moins un nœud relais et un jeton destiné à être fourni par ledit au moins un nœud relais au deuxième terminal.
[Revendication 2] Procédé de gestion selon la revendication 1 dans lequel découvrir ledit au moins un nœud relais comprend recevoir un message provenant du nœud relais ou provenant du deuxième terminal et ayant transité par ledit au moins un nœud relais, comprenant une indication dudit service fourni par ledit nœud relais et un identifiant dudit nœud relais.
[Revendication 3] Procédé de gestion selon la revendication 1 ou la revendication 2 comprenant en outre si le premier terminal accepte la fourniture dudit service par ledit nœud relais, émettre un message à destination du nœud relais ou à destination du deuxième terminal et transitant via ledit nœud relais, comprenant une indication destinée audit nœud relais de l’acceptation dudit service par le premier terminal et un jeton généré par le premier terminal.
[Revendication 4] Procédé de gestion selon la revendication 3, dans lequel le message d’information de relais comprend en outre au moins un élément parmi une information de joignabilité du nœud relais permettant d’accéder audit nœud relais, au moins un identifiant d’au moins une communication entre le premier et le deuxième terminal empruntant un chemin impliquant le nœud relais et un défi généré par le premier terminal.
[Revendication 5] Procédé de gestion selon l’une quelconque des revendications 1 à 4 comprenant vérifier une fiabilité du nœud relais avant d’accepter ledit service.
[Revendication 6] Procédé de gestion selon l’une quelconque des revendications 1 à 5, dans lequel ledit service comprend un accès par le nœud relais à des chemins multiples pour supporter ladite communication entre le premier terminal et le deuxième terminal.
[Revendication 7] Procédé de gestion selon la revendication 3 et la revendication 6 dans lequel ledit message comprend en outre un algorithme de répartition de charge de trafic entre lesdites chemins multiples destiné à être appliqué par le nœud relais.
[Revendication 8] Procédé de gestion selon l’une quelconque des revendications 1 à 7 comprenant, lors de l’établissement ou au cours de ladite communication entre le premier et le deuxième terminal, indiquer au deuxième terminal que le premier terminal supporte une extension du protocole QUIC qui permet l’établissement de ladite communication selon le protocole QUIC sur des chemins multiples, même si un seul chemin est disponible localement au niveau du premier terminal.
[Revendication 9] Procédé de gestion d’une communication établie selon le protocole QUIC entre un premier terminal et un deuxième terminal connectés via un réseau de communication, le procédé comprenant, au deuxième terminal, lors d’une phase d’établissement ou au cours de ladite communication :
recevoir, en provenance du premier terminal, un message d’information de relais chiffré comprenant un jeton et des données identifiant au moins un nœud relais entre le premier terminal et le deuxième terminal apte à fournir au moins un service pour ladite communication.
[Revendication 10] Procédé de gestion selon la revendication 9 comprenant :
mémoriser pour ladite communication ledit jeton et un premier quadruplet comprenant une adresse et un numéro de port source, et une adresse et un numéro port destination du message d’information de relais ;
sur détection, dans un message subséquent de ladite communication en provenance du premier terminal, d’une adresse source différente de l’adresse source du premier quadruplet :
vérifier auprès du nœud relais si ledit message subséquent a transité par le nœud relais ; et le cas échéant, mémoriser pour la communication, un deuxième quadruplet comprenant l’adresse et le numéro de port source, et l’adresse et le numéro de port destination du message subséquent.
[Revendication 11] Procédé de gestion selon la revendication 10 dans lequel le deuxième quadruplet est mémorisé tout en conservant le premier quadruplet.
[Revendication 12] Procédé de gestion selon la revendication 11 comprenant, lors de l’établissement ou au cours de ladite communication entre le premier et le deuxième terminal, indiquer au premier terminal que le deuxième terminal supporte une extension du protocole QUIC qui permet l’établissement de communications selon le protocole QUIC sur des chemins multiples, même si un seul chemin est disponible localement au niveau du deuxième terminal.
[Revendication 13] Procédé de gestion selon l’une quelconque des revendications 10 à 12 dans lequel la vérification comprend :
envoyer un message de demande de vérification au nœud relais comprenant l’adresse source du deuxième quadruplet ou un défi ;
recevoir un message de réponse du nœud relais comprenant un jeton ;
vérifier la coïncidence entre ledit jeton reçu du nœud relais et le jeton mémorisé.
[Revendication 14] Procédé de gestion selon la revendication 13 comprenant, si lesdits jetons coïncident, l’utilisation du deuxième quadruplet par le deuxième terminal pour l’envoi de messages chiffrés au premier terminal.
[Revendication 15] Procédé de gestion d’une communication établie selon le protocole QUIC entre un premier terminal et un deuxième terminal, connectés via un réseau de communication, le procédé étant mis en œuvre par un nœud relais du réseau de communication situé entre le premier et le deuxième terminal et apte à fournir au moins un service pour ladite communication, ledit procédé comprenant :
insérer dans au moins un message destiné au premier terminal, provenant du deuxième terminal et transitant par ledit nœud relais des données indiquant le support par ledit nœud relais dudit service, lesdites données comprenant un identifiant du nœud relais.
[Revendication 16] Procédé selon la revendication 15, dans lequel lesdites données sont comprises dans une option UDP (User Datagram Protocol).
[Revendication 17] Procédé selon la revendication 16 ou la revendication 17 dans lequel ledit service comprend un accès par le nœud relais à des chemins multiples qui permettent de supporter ladite communication entre le premier terminal et le deuxième terminal.
[Revendication 18] Procédé selon l’une quelconque des revendications 15 à 17, dans lequel lesdites données comprennent en outre l’un au moins parmi un identifiant d’offre de service, au moins une information de joignabilité du nœud relais permettant d’accéder audit nœud relais, et des données descriptives du service fourni par le nœud relais.
[Revendication 19] Procédé selon l’une quelconque des revendications 15 à 18, comprenant en outre :
recevoir en provenance du premier terminal un message de ladite communication comprenant une indication d’une acceptation par le premier terminal du service fourni par le nœud relais et un jeton généré par le premier terminal ;
mémoriser dans une table de communications actives pour le premier terminal ledit jeton associé avec ladite communication.
[Revendication 20] Procédé selon l’une quelconque des revendications 15 à 19 comprenant, suite à une acceptation du service fourni par le nœud relais par le premier terminal, modifier une adresse source ou destination et/ou un numéro de port source ou destination d’un message provenant du premier terminal ou du deuxième terminal, destiné au deuxième terminal ou au premier terminal et transitant par le nœud relais qui se charge de relayer ledit message vers le deuxième terminal.
EP20747017.0A 2019-06-28 2020-06-22 Procédé de gestion d'une communication entre terminaux dans un réseau de communication, et dispositifs pour la mise en oeuvre du procédé Pending EP3991391A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR1907090A FR3096533A1 (fr) 2019-06-28 2019-06-28 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é
PCT/FR2020/051080 WO2020260813A1 (fr) 2019-06-28 2020-06-22 Procédé de gestion d'une communication entre terminaux dans un réseau de communication, et dispositifs pour la mise en oeuvre du procédé

Publications (1)

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

Family

ID=68654616

Family Applications (1)

Application Number Title Priority Date Filing Date
EP20747017.0A Pending EP3991391A1 (fr) 2019-06-28 2020-06-22 Procédé de gestion d'une communication entre terminaux dans un réseau de communication, et dispositifs pour la mise en oeuvre du procédé

Country Status (4)

Country Link
US (1) US12255876B2 (fr)
EP (1) EP3991391A1 (fr)
FR (1) FR3096533A1 (fr)
WO (1) WO2020260813A1 (fr)

Families Citing this family (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US12047276B2 (en) * 2019-10-10 2024-07-23 Deutsche Telekom Ag Method and communication device for transmitting multiple data streams of different communication services over a multipath transmission system
CN115244897A (zh) * 2020-02-14 2022-10-25 Idac控股公司 用于使用quic实现多主机多路径安全传输的方法和装置
CN115987536A (zh) * 2021-10-15 2023-04-18 华为技术有限公司 报文源地址识别方法及装置
US12150048B2 (en) * 2021-12-06 2024-11-19 T-Mobile Usa, Inc. Proxy-call session control function (P-CSCF) selection by traffic type
WO2023179891A1 (fr) * 2022-03-23 2023-09-28 Lenovo (Singapore) Ltd. Envoi de données à l'aide d'une direction dans une connexion quic sélectionnée
CN118870565A (zh) * 2023-04-28 2024-10-29 中国移动通信有限公司研究院 终端关联方法、设备及可读存储介质

Family Cites Families (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2007074885A1 (fr) * 2005-12-27 2007-07-05 Matsushita Electric Industrial Co., Ltd. Methode de recherche de noeud mandataire, noeud relais utilise dans la methode,methode de recherche de noeud et premier noeud, deuxieme noeud et noeud mandataire utilises dans la methode
US10904219B2 (en) * 2016-03-02 2021-01-26 Telefonaktiebolaget Lm Ericsson (Publ) Transport relay in communications network
WO2018076183A1 (fr) * 2016-10-25 2018-05-03 华为技术有限公司 Procédé, appareil, et système de transmission de données
US11202230B2 (en) * 2017-05-19 2021-12-14 Telefonaktiebolaget Lm Ericsson (Publ) Technique for enabling multipath transmission
FR3067545A1 (fr) * 2017-06-21 2018-12-14 Orange Procede d'activation de traitements appliques a une session de donnees
US10153978B1 (en) * 2018-05-04 2018-12-11 Nefeli Networks, Inc. Distributed anticipatory bidirectional packet steering for software network functions
WO2020065130A1 (fr) * 2018-09-24 2020-04-02 Nokia Technologies Oy Gestion de sécurité entre un mandataire de périphérie et un nœud d'échange inter-réseaux dans un système de communication
US10951589B2 (en) * 2018-12-06 2021-03-16 Akamai Technologies, Inc. Proxy auto-configuration for directing client traffic to a cloud proxy

Also Published As

Publication number Publication date
WO2020260813A1 (fr) 2020-12-30
US20220311746A1 (en) 2022-09-29
US12255876B2 (en) 2025-03-18
FR3096533A1 (fr) 2020-11-27

Similar Documents

Publication Publication Date Title
EP3476095B1 (fr) Procédé de communication udp via des chemins multiples entre deux terminaux
EP3991391A1 (fr) Procédé de gestion d'une communication entre terminaux dans un réseau de communication, et dispositifs pour la mise en oeuvre du procédé
EP3476096B1 (fr) Procédé de communication udp via des chemins multiples entre deux terminaux
EP3318023B1 (fr) Procédé d'optimisation de la charge d'un concentrateur de connexions réseau
EP3646557A1 (fr) Procédé de communication quic via des chemins multiples
EP3284224B1 (fr) Procédé d'émulation dune connexion à chemins multiples
EP4222994A1 (fr) Procedes de configuration d'un equipement utilisateur, de negociation avec une entite du reseau, et de gestion d'une connexion, et dispositifs associes
FR3072238B1 (fr) Dispositif et procede de transmission de donnees
WO2020002793A1 (fr) Procédé de modification de messages par un équipement sur un chemin de communication établi entre deux nœuds
FR3096532A1 (fr) 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é
FR3122796A1 (fr) Procédé de défense contre une tentative de déconnexion entre deux entités, système associé
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
WO2025133029A1 (fr) Procédé d'accès à un service par un dispositif de communication via au moins un réseau de communication
WO2025078594A1 (fr) Procédés de sélection de tranches réseau adaptées à un service, de gestion d'au moins une tranche réseau et de communication, et entités configurées pour mettre en œuvre ces procédés
WO2025093520A1 (fr) Procédés et dispositifs pour la configuration et l'utilisation d'un réseau supportant des tranches réseau
FR3154268A1 (fr) Procédés de vérification, de gestion, de contrôle, d’exécution d’une vérification de l’accessibilité d’un équipement, équipement, serveur de contrôle, contrôleur réseau, entité relais et programme d’ordinateur correspondants.
EP4631215A1 (fr) Procédé de gestion d'un ensemble d'adresses ip, procédé de collaboration et dispositifs configurés pour mettre en oeuvre ces procédés

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: 20220128

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