WO2021205124A1 - Procede mis en œuvre par une entite intermediaire pour gerer une communication entre deux dispositifs de communication - Google Patents

Procede mis en œuvre par une entite intermediaire pour gerer une communication entre deux dispositifs de communication Download PDF

Info

Publication number
WO2021205124A1
WO2021205124A1 PCT/FR2021/050624 FR2021050624W WO2021205124A1 WO 2021205124 A1 WO2021205124 A1 WO 2021205124A1 FR 2021050624 W FR2021050624 W FR 2021050624W WO 2021205124 A1 WO2021205124 A1 WO 2021205124A1
Authority
WO
WIPO (PCT)
Prior art keywords
communication
identifier
mask
communication device
intermediate entity
Prior art date
Application number
PCT/FR2021/050624
Other languages
English (en)
Inventor
Mohamed Boucadair
Christian Jacquenet
Original Assignee
Orange
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 filed Critical Orange
Priority to EP21724726.1A priority Critical patent/EP4133707A1/fr
Priority to CN202180039694.8A priority patent/CN115699681A/zh
Priority to US17/917,464 priority patent/US20230179578A1/en
Publication of WO2021205124A1 publication Critical patent/WO2021205124A1/fr

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/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • H04L63/0407—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the identity of one or more communicating identities is hidden
    • H04L63/0414—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the identity of one or more communicating identities is hidden during transmission, i.e. party's identity is protected against eavesdropping, e.g. by using temporary identifiers, but is known to the other party or parties involved in the communication
    • 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/0227—Filtering policies
    • H04L63/0236—Filtering by address, protocol, port number or service, e.g. IP-address or URL
    • 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/10—Network architectures or network communication protocols for network security for controlling access to devices or network resources
    • 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 invention relates to the general field of telecommunications. It relates more particularly to the management of a communication between two communication devices (communication termination points) by an entity placed on at least one path of this communication.
  • the present application does not make any assumptions as to the type of these communication devices. They can consist of terminal equipment used by the customers of a network operator, such as, for example, a digital decoder (or “Set Top Box” (STB) in English), a user equipment (or “User Equipment” (UE ) in English), a personal computer (or “Personal Computer” (PC) in English), a smart phone (or “Smartphone” in English), a connected television or a tablet, but also by equipment managed by an operator. 'a telecommunications network (for example, server, firewall, router), this equipment being able to be fixed or mobile.
  • the communication devices can also be software applications, or service instances hosted in equipment.
  • the present application also makes no assumption as to the nature of the entity placed on the communication path (s). Any entity placed on the path taken by the packets exchanged between communication devices as part of their communication can implement the invention.
  • the entity hereinafter called “intermediate entity” may or may not be integrated into one of the communication devices.
  • the invention finds a preferred but non-limiting application in telecommunications networks in which the addresses (IP) of the communication devices are liable to change during a communication.
  • IP network it is in fact known that one or even more IP addresses assigned to a terminal are liable to change during a communication, for example when the terminal is in motion, in particular in a roaming context ("handover ”Or“ roaming ”, in English).
  • the communication identifiers used by the communication devices during a communication are conveyed in clear and can be used by the aforementioned entities, they do not however have the means to correlate these identifiers and therefore associate them with the same communication, when these communication identifiers are modified during the communication.
  • the list of communication identifiers authorized for the QUIC communication was exchanged in an encrypted manner by the two communication devices, which makes it difficult or even impossible for an intermediate entity to associate the various communication identifiers. to the same QUIC communication.
  • control entity in the network (typically an SDN controller (for “Software-Defi ned Networking”), responsible for informing the intermediary entities of a forthcoming modification of a communication identifier.
  • SDN controller for “Software-Defi ned Networking”
  • the control entity may fail to communicate the new communication identifiers to the intermediate entity.
  • the invention is aimed at a solution which does not have the aforementioned drawbacks.
  • the invention relates to a method of managing a communication between at least a first communication device and at least a second communication device in a communication network, the method being implemented by a so-called entity. intermediary placed on at least one path taken by data packets of this communication. This process includes:
  • the invention relates to a so-called intermediate entity configured to be placed on at least one path taken by data packets of a communication between at least a first communication device and at least a second communication device in a communication network.
  • this entity comprising:
  • an obtaining module configured to obtain a communication identifier conveyed in a data packet exchanged during this communication
  • a processing module configured to process this data packet as a function of a result of a verification of a conformity of the communication identifier with at least one communication identifier mask accessible by this intermediate entity.
  • a communication identifier mask is accessible by an intermediate entity as soon as the intermediate entity can be aware of this identifier mask.
  • the communication identifier mask can for example be stored by the intermediate entity, or be obtained by the intermediate entity from another item of equipment via the communication network.
  • the invention relates to a communication method implemented by a first communication device in a communication network, this method comprising:
  • the invention relates to a communication device comprising:
  • a module for generating communication identifiers configured to generate at least one identifier intended to be used as a communication identifier in a communication between this communication device and at least one second communication device in a communication network, this identifier being conforms to at least one communication identifier mask accessible by at least one intermediate entity placed on at least one path taken by data packets of this communication;
  • a module for sending data packets configured to send at least one data packet comprising this identifier as part of this communication.
  • the invention relates to a communication system comprising at least:
  • this communication device being configured to communicate with at least one second communication device;
  • an intermediate entity as mentioned above configured to be placed on at least one path taken by the data packets of a communication established between these communication devices.
  • the intermediate entity in accordance with the invention checks, in order to manage a communication established between two communication devices, whether a communication identifier conveyed in a packet of this communication conforms or not to a identifier mask. For example, in a particular embodiment, the intermediate entity checks whether the communication identifier is formed from at least one communication identifier mask which it can access.
  • Such an intermediate entity is for example an entity located on a path of the envisaged communication and capable of processing data packets exchanged during this communication.
  • Such a mask allows the intermediate entity to manage a communication between the communication devices by applying particular processing to at least some of these packets even if the communication identifiers vary during the communication. Indeed, the intermediate entity does not need to implement a logic or a structure which would establish a history or any link between the communication identifiers used by the different devices during the same communication. This logic is replaced by the simple verification of the conformity of the identifier with the mask.
  • the invention in no way requires the intermediate entity to carry out any encryption / decryption operation, the role of this entity being essentially to verify compliance. from a communication identifier to one or more identifier masks.
  • this operation of verifying said conformity can consist essentially of a comparison and can be carried out by performing a simple logical “AND” (“AND” operand in English) between the identifier and the mask.
  • the invention also does not require the introduction of a control entity (whether centralized or distributed) whose role would be to inform the intermediate entities of future modifications to the communication identifiers (connection migration described above. ). Communication devices can therefore change communication identifiers at any time, without prior notification to an external entity. Thus, and very advantageously, the invention does not complicate the engineering of the network.
  • the cryptographic keys used by the communication devices to encrypt their communications are not communicated to the intermediate entities: the invention thus advantageously avoids introducing a security flaw linked to the use of these intermediate entities.
  • the invention makes it possible to improve the management of network resources and to improve the quality of service provided and perceived by users.
  • a communication identifier generated by a communication device can be used as a source communication identifier in a packet sent by this communication device.
  • the first communication device sends, to the second communication device with which the communication has been established, the communication identifier encrypted in a data packet.
  • the remote communication device uses the received identifier as the destination communication identifier for a subsequent packet of the communication.
  • the processing of a data packet takes account of the conformity of the communication identifier with the communication identifier mask. For example, all the packets received by the intermediate entity, and whose communication identifier does not conform to the mask (for example because the identifier was not formed from the communication identifier mask ad hoc) can be blocked.
  • the intermediate entity implements a firewall function, and receives a mask from a communication device whose communication it manages.
  • the step of processing a data packet comprises the filtering of this packet as a function of the conformity or not of the communication identifier depending, for example, on whether or not it was formed from the mask received from this communication device. communication.
  • the firewall can for example communicate one or more mask generation instructions to the communication devices that it protects and receive, from at least one of these devices, a generated communication identifier mask. on the basis of these instructions, the firewall can be configured to block incoming and / or outgoing packets which convey a communication identifier which does not respect such a mask.
  • This embodiment of the invention can in particular be implemented for:
  • the intermediate entity receives the communication identifier mask from a communication device and associates this mask with this communication device, and the processing step is further determined as a function of the communication device associated with said mask.
  • the communication method according to the invention comprises:
  • the management method according to the invention comprises:
  • the communication identifier mask being received from the communication device in response to the announcement message.
  • the communication method according to the invention comprises a step of reception, by the first communication device, of an announcement message comprising at least one mask generation setpoint coming from an intermediary entity.
  • This particular embodiment of the invention is particularly advantageous when the intermediate entity implements a traffic routing function ("forwarding" in English), or a load sharing function of the traffic intended for several communication devices. , each of these communication devices generating its own communication identifier mask by applying the instruction (s) received.
  • the processing of a packet by the intermediate entity can include checking that a communication identifier of a packet corresponds to a mask of a given communication device and then routing this packet to this given communication device.
  • the announcement message can for example be received in response to a discovery message sent by the first communication device.
  • This particular embodiment allows an intermediate entity to announce itself in the network and to communicate its instruction (s) to the communication devices.
  • this announcement message includes a service identifier which identifies a service whose packets can be processed by the intermediate entity.
  • An intermediate entity in accordance with the invention does not necessarily itself define the instruction or instructions that it uses to verify the conformity of a communication identifier conveyed by a packet that it processes.
  • the management method according to the invention may include a step of receiving, from at least one communication device, at least one mask d 'communication identifier generated by this communication device from at least one setpoint for generating communication identifier masks supplied by another intermediate entity offering this determined function.
  • the first communication device :
  • the packets of the same communication can be routed to the same communication device regardless of the intermediate entity involved in the routing of the packets;
  • the first communication device uses the same communication identifier mask to communicate with the intermediate entities offering the same function.
  • This embodiment of the invention is particularly advantageous because it allows the first intermediate entity to obtain masks generated by applying generation instruction (s) provided by another intermediate entity without there being any have pre-established communication between these intermediary entities.
  • this first intermediary entity can deduce the setpoint (s) for generating communication identifier masks from this other intermediary entity.
  • This embodiment can for example be implemented when a second intermediate entity is introduced to replace a first intermediate entity.
  • the second intermediate entity can simply announce itself to the communication devices, which register with it communication identifier masks in application of the instruction (s) they had received from the first intermediate entity. .
  • the first communication device can generate a communication identifier mask and register it with an intermediate entity without receiving the instruction (s) from this intermediate entity.
  • the management method according to the invention comprises:
  • a conflict detection step a conflict being detected if a communication identifier mask received from a communication device constituting an instance of a service has already been associated by the intermediate entity with at least one other communication device constituting a different instance of the same service;
  • the intermediate entity if it receives from a communication device a registration request for a communication identifier mask already in use, it can reject this registration request or ask the communication device to offer him a new mask.
  • the first communication device checks, before registering, with a first intermediate entity, for a determined service, a mask generated in application of one or more first instructions, that it does not has not already registered with another intermediary, a mask for the same service and generated by applying different instructions.
  • This embodiment makes it possible to avoid conflicts in the generation of masks and consequently of communication identifiers for the same service.
  • the first communication device determines that it has already registered a mask for the same service with another intermediate entity, it registers with the first intermediate entity a mask generated according to these other instructions, so as to guarantee the consistency of the masks.
  • the method of managing a communication according to the invention comprises:
  • a verification step to verify whether the intermediate entity can process the data packets of a communication involving the communication device as a function of:
  • This embodiment advantageously allows the intermediate entity to proceed with the migration of communication identifiers in order to be able to process more communication devices and thus avoid rejecting the registration requests received from the new communication devices.
  • the intermediate entity does not itself generate the communication identifiers. At most, it defines instructions, typically the bits that it will use to perform its service (e.g. check the conformity of communication identifiers formed from a mask, process the packets that it routes according to the mask). These bits are the bits of the communication identifiers that the intermediate entity considers as "significant” because they are those that it analyzes to determine whether or not they conform to the mask (s) of identifiers that it considers. . In the remainder of the description, these bits are designated by “significant bits” of the communication identifier.
  • the instructions for generating a mask of a communication identifier defined in the invention thus make it possible, for example, to determine the position and the value of the significant bits of the communication identifier.
  • these instructions may include:
  • said at least one setpoint for generating a mask comprises at least one item of information from:
  • the communication between the first communication device and the second communication device conforms to a communication protocol based on the UDP transport protocol, for example the QUIC protocol.
  • the QUIC protocol is a transport protocol which is based on the UDP protocol (User Datagram Protocol) and the design and use of which are intended in particular to reduce the latency times generally observed when establishing TCP connections. (Transmission Control Protocol).
  • UDP protocol User Datagram Protocol
  • Transmission Control Protocol Transmission Control Protocol
  • the QUIC protocol is cited by way of example, and the invention can also be applied to other protocols, in particular other protocols based on the UDP protocol, with a privileged application in the context of protocols implementing implements, like QUIC, an encryption of payload data and certain communication control information.
  • the invention also relates to a computer program on a recording medium, this program being capable of being implemented in a computer.
  • This first program includes instructions adapted to the implementation of a communication management method as described above.
  • the invention also relates to a computer program on a recording medium, this program being capable of being implemented in a computer.
  • This second program includes instructions adapted to the implementation of a communication method as described above.
  • Each of these programs can use any programming language, and be in the form of source code, object code, or code intermediate between source code and object code, such as in a partially compiled form, or in any code. what other desirable shape.
  • the invention also relates to an information medium or a recording medium readable by a computer, and comprising instructions of the first or of the second computer program as mentioned above.
  • the information or recording media can be any entity or device capable of storing the programs.
  • the media can comprise a storage means, such as a ROM, for example a CD ROM or a microelectronic circuit ROM, or else a magnetic recording means, for example a floppy disk or a disk. hard, or flash memory.
  • the information or recording media can be transmissible media such as an electrical or optical signal, which can be routed via an electrical or optical cable, by radio link, by wireless optical link or by other ways.
  • the programs according to the invention can in particular be downloaded from an Internet type network.
  • each information or recording medium can be an integrated circuit in which a program is incorporated, the circuit being adapted to execute or to be used in the execution of one of the methods in accordance with the invention.
  • Figure 1 shows a QUIC communication according to the current state of the art
  • Figure 2 shows a QUIC packet according to the present state of the art
  • FIG. 3 shows a QUIC communication between two communication devices according to the current state of the art
  • FIG. 4 illustrates a discovery mechanism that can be implemented in a particular embodiment of the invention
  • FIG. 5 represents an announcement message which can be used in a particular embodiment of the invention
  • FIG. 6 represents a table of instances of intermediate entities that can be used in a particular embodiment of the invention.
  • FIG. 7 represents a registration message which can be used in a particular embodiment of the invention.
  • FIG. 8 represents a table of instances of communication devices which can be used in a particular embodiment of the invention.
  • FIG. 9 represents a format of a mask generation instruction that can be used in a particular embodiment of the invention.
  • FIGS. 10A to 10E represent examples of instructions conforming to the format of FIG. 9;
  • FIG. 11 illustrates the steps of a method for managing a communication in accordance with a particular embodiment of the invention
  • FIG. 12 represents a table of communication devices used in an exemplary implementation of the invention.
  • FIG. 13 represents a process which can be implemented for the activation of an intermediate entity in a particular embodiment of the invention
  • FIG. 14 illustrates a mechanism that can be implemented by a communication device in accordance with a particular embodiment of the invention to optimize the processing of traffic when it receives packets from several intermediate entities in accordance with the invention ;
  • Figure 15 illustrates a process which may be implemented in the invention to remove an intermediary entity
  • FIG. 16 illustrates an example of updating a table of service instances in a particular embodiment of the invention
  • FIG. 17 illustrates a first example for replacing one intermediate entity by another in a particular embodiment of the invention
  • FIG. 18 illustrates a second example for replacing one intermediate entity by another in another particular embodiment of the invention.
  • FIG. 19 illustrates an example for replacing one communication device with another in another particular embodiment of the invention
  • FIG. 20 represents a process for renewing a communication identifier mask at the initiative of a communication device in accordance with a particular embodiment of the invention
  • FIG. 21 illustrates the updating of a table of communication devices in a particular embodiment of the invention following a modification of a communication identifier mask
  • FIG. 22 represents a process for renewing a communication identifier mask at the initiative of an intermediate entity in a particular embodiment of the invention
  • FIG. 23 represents a process for introducing a new communication device in accordance with a particular embodiment of the invention.
  • Figure 24 illustrates a particular embodiment of the invention in which the intermediate entity is a firewall
  • Figure 25 illustrates a communication device table that may be used in the context of the embodiment of Figure 24;
  • Figure 26 shows the hardware architecture of an intermediate entity according to a particular embodiment of the invention
  • Figure 27 shows the hardware architecture of a communication device according to a particular embodiment of the invention
  • Figure 28 shows a system according to a particular embodiment of the invention.
  • the invention is now described in the particular context in which the communication devices establish a communication according to the QUIC protocol.
  • the present invention relates in particular to a method of managing a communication and a method of communication.
  • a “communication” between two items of equipment designates all the exchanges between the establishment, maintenance and termination of this communication.
  • connection identifier in the particular context of the QUIC protocol is a communication identifier within the meaning of the invention.
  • connection identifier or CID for “Connection Identifier” in English
  • FIG. 1 represents a connection (or communication) QUIC CQ between two communication devices PTi and PT2.
  • a QUIC communication makes it possible to multiplex different communication channels G (in English “streams”) in which P data packets are routed.
  • the communication devices PTi and PT2 can for example be a terminal (referenced hereinafter PTUT), a client (referenced PTCT) OR a service instance (referenced PTis).
  • Either of the communication devices can establish a communication channel G.
  • the communication device which is at the origin of the establishment of a channel is called “source” and will be referenced PTso; the other communication device with which this channel is established is called “destination” and will be referenced PTDE.
  • the same communication device may have several references, for example PTis and PTso for a source communication device of the service instance type.
  • a P QUIC packet, represented in FIG. 2 comprises a public ETP header and payload data DU.
  • the payload data DU is encrypted, and includes the communication control information.
  • a QUIC packet comprises a public ETP header comprising itself, flags (FL flags), a communication identifier (or “connection identifier” as indicated above) and a PN packet number.
  • the communication identifier is sent in the clear.
  • the identifier of a communication channel G not shown in FIG. 2, is encrypted.
  • the QUIC connection identifier is an example of the communication identifier described above.
  • the QUIC specification distinguishes the communication identifier associated with the source (and designated “SCID” for “Source Connection Identifier”) from the communication identifier associated with the destination (and designated “DCID” for “Destination Connection Identifier”).
  • the packet in Figure 2 is a QUIC packet with a short ETP header.
  • the public ETP header includes only the communication identifier of the destination, ie the DCID.
  • the QUIC specification also defines a long header comprising the communication identifier of the destination DCID and the communication identifier of the source SCID.
  • connection IDentifier in English
  • the communication identifier CID has two parts, a source part SCID and a destination part DCID.
  • the notion of communication identifier therefore includes both the ⁇ DCID, SCID ⁇ pair as well as each of the identifiers DCID and SCID independently.
  • FIG. 3 represents a QUIC communication established between two communication devices PTi and PT2, an intermediate entity El placed on the path taken by the characteristic packets of this communication and a QUIC P packet of this communication as seen by the intermediate entity EL
  • the intermediate entity El all the data of the packet QUIC (shown hatched) are encrypted, with the exception of the communication identifier SCID or DCID (in the example of a short ETP header).
  • SCID communication identifier
  • DCID in the example of a short ETP header
  • the quadruplet consisting of the source IP address and the source port number of the source communication device and the destination IP address and the destination port number of the destination communication device of the packet;
  • @E denotes the pair ⁇ IP address, port number ⁇ of a device or a function E.
  • intermediate entities implement a traffic load distribution function or a firewall function. These intermediate entities can then be simply referred to as “load balancers”.
  • FIG. 3 also illustrates that a communication device can provide several services, for example served, serv2, serv3, ....
  • servjd will denote the identifier designating such a service.
  • FIG. 4 illustrates how, in a particular embodiment of the invention, a communication device PT in accordance with the invention can:
  • the communication device PT in accordance with the invention sends a discovery message QUERY to detect any intermediate entities E1 in accordance with the invention.
  • the discovery message QUERY is sent to a broadcast address ADDR_S listened to by all the intermediate entities EL
  • the discovery message QUERY includes a service clause fnjd identifying this traffic load balancing function . This clause is optional.
  • the intermediate entities El receive the discovery message QUERY.
  • an intermediate entity El sends, during a step F0410, an announcement message ANNOUNCE to a broadcast address or to a multicast address reserved for this use ADDR_L, the source address of this message being a unicast @EI IP address of the EI intermediate entity.
  • FIG. 5 represents an ANNOUNCE announcement message which can be used in the invention.
  • the announcement message ANNOUNCE may include an IDEI identifier of the intermediate entity El (for example its IP address @EI), an identifier fnjd of the function implemented by this intermediate entity (for example load balancing function, firewall function, ...) and one or more servjd identifiers of the services of the communication device PT to which the intermediate entity El is authorized to offer its function (for example its load balancing function or its firewall function).
  • service identifiers can be defined by an administrator of a network which hosts communication devices in accordance with the invention and providing these services.
  • the intermediate entity E1 offers a traffic load distribution function
  • the ANNOUNCE announcement messages sent by this intermediate entity can include identifiers of the services whose load can be distributed by this entity.
  • These service identifiers can be structured in the form of an alias, a FQDN (Fully Qualified Domain Name), etc.
  • the ANNOUNCE announcement message can also include one or more instructions for generating DG_MASK masks allowing a communication device to create one or more of these masks of communication identifiers in application of these instructions.
  • the communication identifiers created from this mask can be source communication identifiers SCID and / or destination communication identifiers DCID.
  • the intermediate entity By sending its instructions for the generation of masks to the communication devices, the intermediate entity expects these communication devices to generate communication identifier masks in application of these instructions and then to register them with she.
  • These instructions are intended to be used by the intermediate entity to, when it intercepts a packet, determine the mask of the communication identifier SCID or DCID conveyed in this packet from this communication identifier and to check whether this identifier conforms to the identifier mask thus determined.
  • DG_MASK instruction format An example of DG_MASK instruction format will be described with reference to FIG. 9 and examples of instructions using this format will be described with reference to FIGS. 10A to 10E.
  • the announcement message ANNOUNCE may include a “broadcast mode” MD field which defines how a communication device PT must respond to this announcement message.
  • the MD broadcast mode can take two values which define whether the communication device PT must respond to this message by using the ADDR_S broadcast address used in step E0400 or by using a unicast @EI address of the intermediate entity.
  • the announcement message ANNOUNCE includes a parameter defining whether or not the intermediate entity E1 rewrites the address of the packets that it relays to a communication device PT.
  • the communication device PT receives the announcement message ANNOUNCE announcing the presence of the intermediate entity EILB during a step E0410.
  • announcement message ANNOUNCE includes an identifier fnjd of a function which does not correspond to that sought by the communication device PT, the communication device PT ignores the announcement message ANNOUNCE. It is assumed in the example of FIG. 4 that this is not the case.
  • the communication device PT records an identifier IDEI of the intermediate entity EILB in a table of instances of intermediate entities denoted EI_INST and represented by FIG. 6.
  • the communication device PT further records therein the @EI address of the intermediate entity and other information not shown, for example a security context and a timestamp of the last message received from this intermediary entity.
  • the IDEI identifier of the intermediate entity can be generated locally by the communication device PT on the basis of the information conveyed in the announcement message ANNOUNCE. PT communication devices can locally use different IDEI identifiers to identify the same EL intermediary entity
  • the communication device PT generates at least one communication identifier mask CID_MASKEi by applying one or more instructions for generating the DG_MASKEI mask.
  • This communication identifier mask is intended to be used by the communication device PT for its communications involving the intermediate entity EILB. In the embodiment described here, this mask is also intended to be used by the communication device PT for its communications involving one or more other intermediate entities offering the same function (traffic load distribution) as the intermediate entity EILB.
  • the communication device PT records the communication identifier mask CID_MASKEI in the intermediate entity instance table EI_INST in association with the intermediate entity EILB and in association with the other intermediate entities offering the distribution function of traffic load.
  • this mask is initially associated in the table EI_INST with an OFF state representing the fact that it has not yet been accepted by the intermediate entity EL
  • the state associated with a communication identifier mask in a table of instances of intermediate entities EI_INST managed by a communication device can take three values, namely:
  • the “OFF” state representing the fact that the mask is not yet used or is no longer used by the communication device, for example because it has not been accepted by the intermediate entity EL
  • this mask is “inactive”
  • the table of instances of intermediate entities EI_INST also stores the servjd identifiers of the services provided by communication devices which can be accessed according to the execution of the function offered by the intermediate entity (distribution traffic load, firewall, ).
  • the communication device PT sends in unicast mode (or broadcasts) a REGISTER registration message comprising the communication identifier mask CID_MASKEI to register this mask with the intermediate entity El, at find out here from the EILB load balancer.
  • This message may include a servjd service identifier corresponding to the service provided, if applicable, by the communication device PT.
  • the communication device sends in unicast mode (or broadcasts) the REGISTER registration message in accordance with the MD broadcast mode included in the ANNOUNCE announcement message received at step E0410: the destination address is either the unicast @EI IP address of the EILB intermediate entity or the ADDR_S broadcast address.
  • the source address of the REGISTER message is a unicast @PT IP address assigned to the communication device.
  • This REGISTER registration message can be sent several times to refresh the registration of the communication identifier mask CID_MASKEI with the intermediate entities El concerned, here, with the load balancer EILB.
  • the REGISTER registration message further comprises an identifier IDPT of the communication device PT.
  • the identifier of the communication device used in the REGISTER registration message is the IP address (and the port) @PT used by said communication device .
  • This identifier can also be an alias, a domain name, etc.
  • the identifier used by an intermediary entity to identify a communication device is a decision local to the entity.
  • this identifier can be the DNS-ID field of the ClientHello Message.
  • the REGISTER registration message is received by one or more intermediate entities E1 during a step F0440; this intermediate entity E1 records the identifier of the communication device PT in a table of instances of communication devices PT_INST, an example of which is illustrated in FIG. 8.
  • the intermediate entity E1 also records in the table of instances of communication devices PT_INST an IP address @PT of the communication device PT. It can also store there a MAC address of the communication device as well as a security context; this latter information is not represented in the PT_INST table in figure 8.
  • the intermediate entity El checks, during a step F0450, whether the communication identifier mask CID_MASKEI received at step F0440 is identical to a communication identifier mask already received for another instance of the same service. This situation constitutes a conflict within the meaning of the invention.
  • the intermediate entity if it detects such a conflict, it sends, during a step F0460 a CONFLICT message of conflict signaling to the communication device PTis. Otherwise it records the CID_MASKEI communication identifier mask in the table of instances of PT_INST communication devices in association with an ON state representative of the use of this mask by the PTis communication device and sends an acknowledgment (acknowledgment , ACK for "acknowledgment" in English) to this communication device PTis.
  • the state associated with a communication identifier mask in a table of instances of communication devices PT_INST managed by an intermediate entity El can take three values, namely:
  • the end of activity state “OBT” indicating that the mask is active but that it will become inactive, for example after a determined deadline or after the end of the last active communication between this intermediate entity and the communication device.
  • an intermediate entity E1 detects a conflict if it identifies in its table of instances of communication devices PT_INST, two records comprising the same communication identifier mask in the ON state associated with two different instances of the same service.
  • the conflict signaling CONFLICT message or the positive acknowledgment ACK is received by the communication device during a step E0460.
  • the communication device PT executes again:
  • step E0430 to generate at least one other CID_MASKEI2 communication identifier mask using the DG_MASKEI mask generation instructions, then to record this new CID_MASKEI2 communication identifier mask in the table of instances of intermediate entities EIJNST;
  • step E0440 to send a REGISTER registration message comprising the new communication identifier mask CID_MASKEI2 in order to register it with the intermediate entity EI.
  • This procedure can be repeated several times, until the intermediate entity E1 considers that the communication identifier mask CID_MASKEI2 received from the communication device PT in step F0440 does not conflict with a mask of communication identifier used by another endpoint.
  • the communication device PT receives at step E0460 an acknowledgment message ACK, it considers that the communication identifier mask CID_MASKEI is confirmed and it modifies its state to ON in its table. EI_INST of instances of intermediate entities.
  • FIG. 9 represents a format of instructions for generating DG_MASK masks that can be supplied by an intermediate entity E1 to a communication device PT to enable it to generate a communication identifier mask from which it can generate communication identifiers.
  • these DG_MASKEI instructions can include:
  • nb_sb integer indicating the number of "significant" bits of the communication identifier, that is to say, as mentioned previously, those which should be considered to check the conformity of the identifier with the mask ;
  • offset_sb integer indicating the offset of the first significant bit of the communication identifier
  • demux_sb integer indicating the position of the significant bits of the communication identifier
  • Figure 10A provides an example in which the offset_sb offset is not provided, the number nb_sb of significant bits is equal to 32 and the integer demux_sb is not provided: the significant bits of the mask are the first 32 bits of a communication identifier.
  • the communication device can thus choose a mask from among the values between “0” and “
  • the value chosen by a communication device will be positioned in the first 32 bits of all the communication identifiers chosen by this communication device.
  • FIG. 10B provides an example in which the offset offset_sb is equal to 32, the number nb_sb is equal to 32 while the integer demux_sb is not supplied: the significant bits are the bits at position 33 to 64 of an identifier Communication.
  • the communication device can thus choose a mask from among the values between “0” and “4294967295”, ie 232 values. The value chosen by a communication device will always be positioned in bits 33 to 64 of all the communication identifiers chosen by this communication device.
  • Figure 10C provides an example in which the offset_sb offset is equal to 48, the number nb_sb of significant bits is equal to 16 while the integer demux_sb is not provided: the significant bits are the bits at position 49 to 64 d 'a communication identifier.
  • the communication device can thus choose a mask from among the values between “0” and “65535”, ie 2 16 values. The value chosen by a communication device will always be positioned in bits 49 to 64 of all the communication identifiers chosen by this communication device.
  • Figure 10D provides an example in which the offset_sb offset is equal to 32, the nb_sb number of significant bits is equal to 32, and the integer demux_sb is equal to 1897 (i.e. the binary value 00000 .... 11101101001): the significant bits are bits 54, 55, 56, 58, 59, 61 and 64 of a communication identifier.
  • the communication device can thus choose a mask from among the 128 possible values while respecting the position of the 7 significant bits, for example 1793, 1856, 1889, 18896, ...
  • Figure 10E provides an example in which the offset offset_sb is not provided, the number nb_sb of significant bits is equal to 32, and the integer demux_sb is equal to 789 (i.e. the binary value 0000000 .... 1100010101): the significant bits are bits 23, 24, 28, 30 and 32 of a communication identifier.
  • the communication device can thus choose a mask from among the 32 possible values while respecting the position of the 5 significant bits, for example 21, 533, 722, 788, ...
  • a last_sb position of the last significant bit can be used instead of the integer demux_sb.
  • FIG. 11 illustrates steps of a method for managing a communication in accordance with one embodiment of the invention.
  • an intermediate entity El sends during a step Fl 100 an announcement message ANNOUNCE with instructions for generating DG_MASK masks in which the offset offset_sb is not supplied, the number nb_sb of significant bits is equal to 32 and the integer demux_sb is equal to 789.
  • a first communication device PTi receives this announcement message (step E1 100), generates a mask 21 in application of the DG_MASK instructions, and requests the registration of this mask 21 by the intermediate entity E1 at the step E1102.
  • a second communication device PT2 receives this announcement message (step E1 103), generates the mask 533 in application of the DG_MASK instructions and requests the registration of this mask 533 by the intermediate entity EILB from the step El 104.
  • the intermediate entity E1 records these masks during a step F1 105 in its table of instances of communication devices PT_INST, the latter being represented by FIG. 12.
  • the first communication device PTi generates, during a step E1 106, a communication identifier equal to 16415 and uses this identifier as the source communication identifier SCID to communicate with a communication device PTCT, this SCID communication identifier being effectively compliant since it is formed from the mask 21.
  • this communication device PTCT sends, in step E1107 to the first communication device PTi, a data packet comprising the value 16415 as the destination communication identifier DCID.
  • the intermediate entity El intercepts this packet in step F1 107 and checks whether the communication identifier DCID conveyed in clear in this packet is compliant, that is to say formed (or even produced or generated ) from a mask saved in its PT_INST communication device instance table.
  • the intermediate entity El can process the communications received and direct them to the various communication devices RTi, PT2.
  • the invention is particularly advantageous when the intermediate entity El is a load balancer EILB and the communication devices of the instances PTisi, PTis2 of the same service. Indeed, when a new communication is intercepted by this intermediate load balancing entity, typically with a destination communication identifier DCID equal to 0, it selects a service instance PTisi or PTis2 according to a load balancing algorithm. of traffic with which it was configured. Communication is then established with the selected instance.
  • This service instance selects a communication identifier that it transmits to the remote communication device PTCT as the source communication identifier SCID, this identifier being compliant because it is formed from the mask generated in application of the DG_MASKEI mask generation instructions. received from the load balancer.
  • the EILB load balancer does not need to maintain a state to process the traffic received from the remote communication device PTCT for this communication. Indeed, when a packet of an already established communication is received by the load balancer EILB, during a new occurrence of step F1 107, the latter extracts the destination communication identifier DCID, extracts the mask therefrom. , and then consults its PT_INST table to identify the service instance that matches this mask.
  • the first service instance PTisi generates new communication identifiers (16381 and 11223) corresponding to the mask generated from the DG_MASKEI instructions received from the load balancer EILB, and proposes to the communication device remote PTCT these new communication identifiers (16381 and 11223) in an encrypted message (step E1108).
  • the message (s) transmitting the new communication identifiers being encrypted, its content is not accessible by the EILB load balancer.
  • the remote communication device PTCT therefore uses the communication identifier 16381 (respectively, 11223) as DCID inserted in the packets of this communication established with the first service instance PTisi.
  • the intermediate entity EILB When the packets are intercepted by the intermediate entity EILB, the latter extracts the communication identifier DCID 16381 (respectively, 11223), extracts the mask 21, and then consults its table of instances of communication devices PT_INST for find the service instance that matches this mask. In this way, all the intercepted packets are sent to the same PTisi service instance.
  • an intermediate entity E1 can further verify (as illustrated in steps F1 106 and F1 108) whether the source communication identifier SCID used by a communication device PT corresponds to the mask which has been communicated to it. . If this is not the case, the intermediate entity can trigger a communication identifier mask negotiation procedure.
  • This variant makes it possible to detect an anomaly in its PT_INST table of instances of communication devices.
  • FIG. 13 represents in the form of a flowchart a process that can be implemented for the activation of an intermediate entity EI2 in a particular embodiment of the invention.
  • this new intermediate entity EI2 sends, during a step F1300, an announcement message ANNOUNCE of the same type as that sent to step F0410 already described.
  • This ANNOUNCE announcement message can include instructions for generating DG_MASKEI2 masks and one or more servjd identifiers of the communication device services which can be processed by the function supported by the intermediate entity (traffic load distribution, firewall ).
  • announcement message ANNOUNCE is received during a step E1300 by a communication device PT which provides several services for example served, serv2, serv3, ....
  • the communication device PT checks (step E1310) whether the ANNOUNCEMENT message includes a service identifier servjd and, if applicable, whether the instance table EI_INST of intermediate entities maintained by this communication device, of the type described in FIG. 6, already comprises an entry for the service identified by servjd, associated with one or more instructions for generating DG_MASKEII masks different from those DG_MASKEI2 received in this announcement message.
  • the communication device PT does not create a new entry in the EI_INST instance table, to guarantee that this table does not contain instructions for generating different DG_MASKEII, DG_MASKEI2 masks for the same servjd service.
  • EI2 can offer the same function (traffic load distribution, firewall) to the same servjd service, on condition that they provide instructions for the generation of consistent DG_MASKEI masks.
  • the communication device PT responds to the announcement message by sending the intermediate entity EI2, during a step E1320, a REGISTER registration message comprising an identifier mask of CID_MASKEH communication generated in application of the mask generation instructions received from the intermediate entity Eli.
  • the communication device PT determines in step E1310 that there is no conflict, it generates a communication identifier mask CID_MASKEI2 in application of the instructions conveyed in the announcement message received in step E1300 then saves it.
  • the packets received by the service instance PTis include a source IP address @EIi when they are received from the intermediate entity Eli and a source IP address @Eb when they are received from the intermediate entity EI2, these packets comprising the same communication identifier SCID or DCID.
  • this protocol provides, in such a situation, for the communication device PTis to send PATH_CHALLENGE messages on the occasion of each change of source IP address. .
  • the purpose of these PATH_CHALLENGE messages is to verify that the PTCT client is legitimately authorized to use a path to send its packets.
  • the communication device PTis does not send, at least during a determined period D, for example 60s, such PATH_CHALLENGE message but maintains (step E1410) two entries in its EI_INST table of instances of intermediate entities.
  • the PTis service instance communication device migrates the QUIC communication to the new IP address if it has not received a packet with another source address during the duration D.
  • This migration consists of deleting, removing step E1420, the entry corresponding to the old IP address in the EI_INST table.
  • the service instance PTis can send the PATH CHALLENGE message to the PTCT client in order to detect a possible attack. But this operation is not necessary for the implementation of this particular embodiment of the invention.
  • FIG. 15 shows in flowchart form a process that can be implemented to withdraw an intermediate entity EL
  • the intermediate entity El wishing to withdraw sends in unicast (or broadcasts), during a step F1500, a BYE withdrawal message from the communication devices PT associated with an active communication identifier mask in its table of instances of communication devices PT_INST.
  • a communication device PT receives this BYE withdrawal message during a step E1500.
  • the communication device PT updates the table EI_INST of instances of intermediate entities, and more precisely the state associated with the communication identifier mask CID_MASKEI used for this intermediate entity EI.
  • the state is modified to take the end of activity value OBT to allow it to continue to temporarily process communications with this intermediate entity EL
  • Figure 16 illustrates the E1510 update of the EI_INST table of service instances.
  • the communication device PT sends an acknowledgment of receipt ACK to the intermediate entity El to inform it that the BYE withdrawal message has been taken into account.
  • a communication device PT when a communication device PT receives a BYE withdrawal message from an intermediate entity, it continues to use the active CID_MASKEI mask for this intermediate entity either for a determined period indicated in the message of BYE withdrawal, ie as long as there is an established communication with this intermediary entity EI.
  • FIG. 17 illustrates an example of replacement of an intermediate entity Eli by an intermediate entity Eb which can be implemented in a particular embodiment of the invention.
  • the intermediate entity EI2 sends to a communication device PT, during a step F1700, an announcement message ANNOUNCE comprising one or more instructions for generating DG_MASKEII masks identical to those previously announced by the entity intermediary Eli.
  • the communication device PT processes this announcement message as described with reference to FIG. 4 to generate an identifier mask in application of these instructions then that it requests the registration of this mask from the entity.
  • intermediate EI2 during a step E1702.
  • the intermediate entity EI2 acknowledges receipt of this recording during a step F1706.
  • step F7104 similar to step F1500, the intermediate entity Eli sends a BYE withdrawal message to the communication device PT to inform it that it is withdrawing.
  • the communication device PT acknowledges receipt of this withdrawal during a step E1708.
  • FIG. 18 illustrates an example of replacement of a first intermediate entity EL by a second intermediate entity EL, this example being able to be implemented in another particular embodiment of the invention. It is assumed in this example that a communication device PT has previously received an announcement message ANNOUNCE from the first intermediate entity Eli comprising first mask generation instructions DG_MASKi for a function fnjd and that this communication device has generated a mask of communication identifier CID_MASKEII in application of these first instructions.
  • the table of instances of intermediate entities EI_INST of the communication device PT comprises a recording of this mask CID_MASKEII in association with the intermediate entity Eli.
  • an announcement message ANNOUNCE comprising instructions for generating DG_MASK2 masks different from the instructions DG_MASKi, for the same function fnjd .
  • the communication device responds to the ANNOUNCEMENT announcement message received from the second entity EI2, during a step E1804, with a REGISTER registration message comprising the same information as those sent previously to the first entity Eli and in particular the communication identifier mask CD_MASKEII generated in application of the DG_MASKi instructions of the first intermediate entity Eli and not in application of the DG_MASK2 instructions of the second intermediate entity EI2.
  • the intermediate entity EI2 acknowledges receipt of this recording during a step F1807.
  • step F1806 similar to step F1704, the intermediate entity Eli sends a BYE withdrawal message to the communication device PT to inform it that it is withdrawing.
  • the communication device PT acknowledges receipt of this withdrawal during a step E1809.
  • FIGS. 17 and 18 illustrate situations in which an intermediate entity Eli must be withdrawn while an intermediate entity EI2 must be activated.
  • the communication device receives a BYE withdrawal message from the intermediate entity Eli and an announcement message ANNOUNCE from the intermediate entity EI2.
  • the communication device PT can update its table EI_INST of instances of intermediate entities to indicate that the intermediate entity Eli will soon be unavailable.
  • the communication device can then migrate communications to the intermediate entity EI2 or maintain the two contexts during a transition period. For example, a communication having been established with a communication identifier SCID or DCID can be routed via the intermediate entity EI2 without modification of the communication identifier and without interruption of communication.
  • the two LB_ANNOUNCE announcement and BYE takedown messages can be received in any chronological order.
  • Fig. 19 shows in flowchart form a process that can be implemented to remove a communication device PT.
  • the communication device PT broadcasts (or sends in a unicast mode), during a step E1900, a BYE withdrawal message to the relevant intermediate entities El, that is to say associated with a mask of active communication identifier as recorded in the intermediate entity instance table EI_INST maintained by the communication device.
  • An intermediate entity E1 receives this BYE withdrawal message during a step F1900.
  • the intermediate entity E1 updates the table PT_INST of instances of communication devices, and more precisely the state associated with the communication identifier mask CID_MASKEI active for the communication device PT.
  • the state is modified to take the end of activity value OBT indicating that the mask is still active but intended to become inactive, for example after a determined deadline or after the termination of the last active communication. established between this intermediate entity and the communication device.
  • FIG. 20 represents a process for renewing a communication identifier mask at the initiative of a communication device PT.
  • a communication device PT can modify a communication identifier mask CID_MASKEI by sending to an intermediate entity El associated with an active communication identifier mask as recorded in the table d 'EI_INST instances maintained by the communication device, during a step E2000, a mask modification UPDATE message to register with this entity a new CID_MASKEI mask' generated in application of the same instructions as CID_MASKEI used by the communication device for this entity.
  • the intermediate entity El receives this message during a step F2000.
  • the mask modification UPDATE message includes the new mask CID_MASKEI 'and possibly a deadline for the activation of this new mask. In the embodiment of the invention described here, this deadline is optional and in the absence of a deadline, the intermediate entity considers that the modification request must be processed immediately.
  • the intermediate entity El does not immediately replace the old mask CID_MASKEI by the new mask CID_MASK'EI in its table of instances of communication devices PT_INST .
  • FIG. 21 illustrates the table of instances of communication devices PT_INST managed by the intermediate entity El after receipt of the UPDATE message: the new mask is associated with an “ON” state and the old one with an end of activity state. "OBT".
  • the intermediate entity El sends an acknowledgment message to the communication device during a step F2010 to indicate to it the correct reception of the mask modification message.
  • the communication device receives this acknowledgment of receipt (step E2010), it can start to use the new CDI_MASK'EI mask.
  • FIG. 22 represents in the form of a flowchart a process for renewing a communication identifier mask at the initiative of an intermediate entity.
  • an intermediate entity E1 can ask the communication devices to modify their communication identifier mask CID_MASKEI by sending them a RESET renewal message, during a step E2200.
  • the communication device PT registers (step F2210) a new mask CID_MASK'EI with this entity E1, the latter being generated in application of the latest instructions supplied by this entity.
  • this message includes new DG_MASK'EI instructions
  • the communication device PT records these new instructions, generates a new CID_MASK'EI mask in application of these new instructions and registers this new mask with the entity EL
  • the RESET mask renewal message may include a deadline for its activation. In the embodiment of the invention described here, this deadline is optional and in the absence of a deadline, the intermediate entity considers that the renewal request must be processed immediately.
  • the RESET renewal message includes new DG_MASK'EI instructions, it is preferable to choose a sufficiently long time to avoid conflicts of communication identifiers.
  • the intermediate entity El does not immediately replace the old mask CID_MASKEI by the new mask CID_MASK'EI in its table of instances of PT_INST communication devices: the new mask is associated with an “ON” state and the old one with an “OBT” end-of-activity state.
  • Figure 23 shows in flowchart form a process that can be implemented to introduce a new PT communication device, for example a new PTis service instance to replace another service instance or increase the processing capacity of a service .
  • a new communication device PT when introduced, it sends, during a step E2300, a discovery message QUERY identical to that sent to step E0400 already described.
  • An intermediate entity E1 responds to it with an announcement message ANNOUNCE identical to that described with reference to step F0410 (step F2310) and the communication device PT proceeds to register its communication identifier mask (step E2320). ).
  • the intermediate entity E1 checks during a step F2330 whether the instructions for generating masks of communication identifiers that it provides the service instances which declare themselves to it to generate masks of communication identifiers (see steps F0410 or F1300) comprising enough bits to allow the service instances active with it and the new instance to service to generate masks and thus allow it to process the packets sent by or to these different service instances.
  • This information is sufficient to allow the intermediate entity El to determine whether the instructions have sufficient significant bits to meet the needs of a new service instance, knowing that the theoretical maximum number of service instances that can be served is 2 n .
  • the intermediate entity El sends, during a step F2340, a RESET renewal message with new DG_MASK'EI instructions comprising enough significant bits to ask the communication devices PTis concerned to generate a new CID_MASKEI mask and register it with this EL entity
  • nb is the number of service instances to be served by the intermediate entity
  • the number of significant bits of the new DG_MASK'EI instructions can be chosen equal to:
  • FIG. 24 illustrates a particular embodiment of the invention in which the intermediate entity is an EIFW firewall, to improve the level of security offered to communication devices, for example terminals RTuti, PTUT2 and PTUT3 protected by this firewall.
  • the intermediate entity is an EIFW firewall
  • This embodiment of the invention can in particular be used to guard against attacks known by the English expression “connection injection”, in which, even in presence of a firewall, an SA attacker successfully sends traffic emitted with a spoofed IP address of a legitimate communication device, for example an instance of PTis.
  • the intermediate entity E1 TM of the firewall type can maintain in its PT_INST table of instances of communication devices:
  • the PT_INST table can in particular contain two masks CID_MASK IN EI and CID_MASK 0UT EI to control the incoming communications and the outgoing communications of the same terminal.
  • the PT_INST table of communication devices includes an IN / OUT attribute making it possible to determine whether a communication identifier mask associated with a terminal must be used to control the communication devices. incoming or outgoing communications from this terminal.
  • the same mask is used to filter the incoming and outgoing communications of a communication device, but the invention does not impose it.
  • the E1 TM firewall obtains (step F2400) the communication identifier SCID, DCID conveyed in the packets exchanged between the terminals RTuti, PTUT2 and PTUT3 on the one hand and the instance of PTis service on the other hand to control the incoming and outgoing communications of the PTUTI and PTUT2 terminals.
  • the firewall is able to block:
  • FIG. 26 represents the hardware architecture of an intermediate entity E1 in accordance with a particular embodiment of the invention.
  • this intermediate entity has the hardware architecture of a computer. It comprises a processor 261, a ROM type read only memory 262, a random access memory 263 and a rewritable non-volatile memory 264, and communication means 265.
  • the read only memory 262 comprises a computer program 266 comprising instructions which, when they are executed by the processor 261, implement a communication management method in accordance with the invention and in particular the steps FXX described above.
  • the rewritable non-volatile memory 264 includes in particular:
  • the P packets and the various messages recalled above are stored in the random access memory 263 while they are being processed by the processor 261.
  • FIG. 27 represents the hardware architecture of a communication device PT in accordance with a particular embodiment of the invention.
  • this communication device has the hardware architecture of a computer. It comprises a processor 271, a ROM type read only memory 272, a random access memory 273, a rewritable non-volatile memory 274, and communication means 275.
  • the read only memory 272 comprises a computer program 276 comprising instructions which, when they are executed by the processor 271, implement a communication method in accordance with the invention and in particular the EXX steps described above.
  • the rewritable non-volatile memory 274 includes:
  • the P packets and the various messages recalled above are stored in the random access memory 273 while they are being processed by the processor 271.
  • the communication means 265 and 275 are configured to communicate according to the QUIC protocol.
  • the communication means 265 of the intermediate entity are configured to intercept the P packets conforming to the QUIC protocol exchanged by the communication means 275 of PT communication devices. These means of communication are also configured to be able to send or receive the messages recalled above.
  • FIG. 28 represents a SYS system according to a particular embodiment of the invention.
  • This system comprises two communication devices RTi, PT2 and an intermediate entity El in accordance with a particular embodiment of the invention, the intermediate entity being placed on a path used to establish communications between these communication devices.
  • FIG. 28 shows the functional architecture of the intermediate entity El and the functional architecture of the communication devices PTi and PT2.
  • the intermediate entity El comprises:
  • an obtaining module MO configured to obtain a communication identifier SCID, DCID conveyed in a packet exchanged during said communication;
  • a processing module MT configured to process this packet as a function of a result of a verification of a conformity of said communication identifier SCID, DCID according to at least one CID_MASKEI communication identifier mask accessible by the intermediate entity EL
  • the PTi communication device comprises:
  • a module MG for generating communication identifiers configured to generate at least one communication identifier intended to be used as a communication identifier SCID, DCID in a communication established between the communication device PTi and the communication device PT2 in a network communication, this identifier being compliant according to at least one CID_MASKEI communication identifier mask accessible to the intermediate entity El;
  • a packet sending module ME configured to send at least one data packet comprising this communication identifier SCID, DCID as part of this communication.
  • modules can be implemented by the hardware and software means of a communication device shown in FIG. 26.

Landscapes

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

Abstract

Ce procédé de gestion d'une communication entre au moins un premier dispositif de communication (PT1) et au moins un deuxième dispositif de communication (PT2) dans un réseau de communication est mis en œuvre par une entité dite intermédiaire (EI) placée sur au moins un chemin emprunté par des paquets de données de ladite communication. Il comporte : - une étape (F1107, F1106) d'obtention d'un identifiant de communication (SCID, DCID) compris dans un paquet de données échangé au cours de ladite communication; et - une étape de traitement dudit paquet de données en fonction d'un résultat d'une vérification d'une conformité dudit identifiant de communication (SCID, DCID) avec au moins un masque d'identifiant de communication accessible par ladite entité intermédiaire (EI).

Description

Description
Titre de l'invention : Procédé mis en œuvre par une entité intermédiaire pour gérer une communication entre deux dispositifs de communication
Technique antérieure
L'invention se rapporte au domaine général des télécommunications. Elle vise plus particulièrement la gestion d'une communication entre deux dispositifs de communication (points de terminaison de la communication) par une entité placée sur au moins un chemin de cette communication.
La présente demande ne fait pas d'hypothèse quant au type de ces dispositifs de communication. Ils peuvent être constitués par des équipements terminaux utilisés par les clients d'un opérateur réseau, comme par exemple, un décodeur numérique (ou « Set Top Box » (STB) en anglais), un équipement utilisateur (ou « User Equipment » (UE) en anglais), un ordinateur personnel (ou « Personal Computer » (PC) en anglais), un téléphone intelligent (ou « Smartphone » en anglais), une télévision connectée ou une tablette, mais également par des équipements gérés par un opérateur d'un réseau de télécommunications (par exemple, serveur, pare-feu, routeur), ces équipements pouvant être fixes ou mobiles. Les dispositifs de communication peuvent également être des applications logicielles, ou des instances de service hébergées dans un équipement.
La présente demande ne fait pas non plus d'hypothèse quant à la nature de l'entité placée sur le(s) chemin(s) de la communication. Toute entité placée sur le chemin emprunté par les paquets échangés entre des dispositifs de communication dans le cadre de leur communication peut mettre en œuvre l'invention. L'entité, ci-après appelée « entité intermédiaire » peut être ou non intégrée à l'un des dispositifs de communication.
L'invention trouve une application privilégiée mais non limitative dans les réseaux de télécommunications dans lesquels les adresses (IP) des dispositifs de communication sont susceptibles de changer au cours d'une communication.
Elle s'applique en particulier dans le contexte d'un réseau IP. Dans un tel réseau, on sait en effet qu'une voire plusieurs adresses IP affectées à un terminal sont susceptibles de changer au cours d'une communication, par exemple lorsque le terminal est en mouvement, notamment dans un contexte d'itinérance (« handover » ou « roaming », en anglais).
Des solutions pour s'adapter à de telles situations, par exemple les solutions qui reposent sur l'activation de protocoles tels que le protocole QUIC, identifient une communication entre deux dispositifs de communication par un identifiant spécifique (« Connection IDentifier » (CID) en anglais dans le cas du protocole QUIC). Cet identifiant est indépendant des adresses IP et des numéros de port utilisés par les dispositifs de communication durant une communication donnée. Cet identifiant est appelé ci-après, « identifiant de communication ». Pour renforcer la sécurité des communications et rendre plus difficile leur traçage, le protocole QUIC permet de faire varier l'identifiant de communication au cours d'une communication, sans clôturer ladite communication. Plus précisément, un dispositif de communication communique à l'autre dispositif de communication une liste d'identifiants que ce dernier peut utiliser au cours de la communication. Dans le cas du protocole QUIC (qui chiffre non seulement les données utiles mais également la plupart des informations caractéristiques de la communication), cette liste d'identifiants est transmise par un dispositif de communication à l'autre dispositif de communication de façon sécurisée, via un mécanisme de chiffrement.
Il est donc très difficile pour une entité telle qu'un pare-feu ou un répartiteur de charge, placée sur un chemin emprunté par les communications établies entre les deux dispositifs de communication, d'être impliquée dans la gestion de telles communications (par exemple, afin d'optimiser l'usage des ressources mobilisées pendant le temps que dure la communication) ou d'appliquer des traitements déterministes sur les paquets caractéristiques de ces communications (un tel traitement est par exemple, la sélection d'une même instance de service pour servir la communication tout au long de la durée de vie de cette communication). En effet, si dans le cas du protocole QUIC, les identifiants de communication utilisés par les dispositifs de communication lors d'une communication sont véhiculés en clair et peuvent être exploités par les entités précitées, celles-ci ne disposent pas en revanche de moyens pour corréler ces identifiants et donc les associer à une même communication, lorsque ces identifiants de communication sont modifiés lors de la communication. En effet, et comme indiqué précédemment, la liste des identifiants de communication autorisés pour la communication QUIC a été échangée de manière chiffrée par les deux dispositifs de communication, ce qui rend difficile voire impossible pour une entité intermédiaire d'associer les différents identificants de communication à une même communication QUIC.
Pour remédier à ce problème, il peut être envisagé d'impliquer l'entité intermédiaire dans le mécanisme de chiffrement précité (l'entité intermédiaire se comportant alors comme un « proxy » ayant accès aux données chiffrées par les dispositifs de communication). Cependant, cette solution n'est pas satisfaisante car elle impacte fortement les performances de cette entité (et donc l'experience perçue par les utilisateurs) en raison des opérations de déchiffrement (et éventuellement, de chiffrement) qu'elle doit mettre en œuvre. Elle fragilise aussi la robustesse des communications en cas d'indisponibilité de cette entité intermédiaire.
Il peut aussi être envisagé d'introduire une entité de contrôle dans le réseau (typiquement un contrôleur SDN (pour « Software- Défi ned Networking » en anglais)), chargée d'informer les entités intermédiaires d'une modification à venir d'un identifiant de communication. Mais une telle solution nécessite de prévenir cette entité de contrôle avant toute migration de connexion (c-à-d., modification et utilisation effective de l'identifiant de communication), ce qui augmente considérablement le trafic de signalisation et pénalise de fait la durée nécessaire pour effectuer la migration de connexion. En outre, l'entité de contrôle peut échouer à communiquer les nouveaux identifiants de communication à l'entité intermédiaire.
L'invention vise une solution qui ne présente pas les inconvénients précités.
Exposé de l'invention
Ainsi selon un premier aspect, l'invention concerne un procédé de gestion d'une communication entre au moins un premier dispositif de communication et au moins un deuxième dispositif de communication dans un réseau de communication, le procédé étant mis en œuvre par une entité dite intermédiaire placée sur au moins un chemin emprunté par des paquets de données de cette communication. Ce procédé comporte :
- une étape d'obtention d'un identifiant de communication véhiculé dans un paquet de données échangé au cours de cette communication, et
- une étape de traitement du paquet de données en fonction d'un résultat d'une vérification d'une conformité de l'identifiant de communication avec au moins un masque d'identifiant de communication accessible par l'entité intermédiaire.
Corrélativement, l'invention concerne une entité dite intermédiaire configurée pour être placée sur au moins un chemin emprunté par des paquets de données d'une communication entre au moins un premier dispositif de communication et au moins un deuxième dispositif de communication dans un réseau de communication, cette entité comportant :
- un module d'obtention configuré pour obtenir un identifiant de communication véhiculé dans un paquet de données échangé au cours de cette communication; et
- un module de traitement configuré pour traiter ce paquet de données en fonction d'un résultat d'une vérification d'une conformité de l'identifiant de communication avec au moins un masque d'identifiant de communication accessible par cette entité intermédiaire.
Au sens de l'invention, on considère qu'un masque d'identifiant de communication est accessible par une entité intermédiaire dès lors que l'entité intermédiaire peut avoir connaissance de ce masque d'identifiant. Le masque d'identifiant de communication peut par exemple être mémorisé par l'entité intermédiaire, ou être obtenu par l'entité intermédiaire auprès d'un autre équipement via le réseau de communication.
Selon un deuxième aspect, l'invention concerne un procédé de communication mis en œuvre par un premier dispositif de communication dans un réseau de communication, ce procédé comportant :
- une étape de génération d'au moins un identifiant destiné à être utilisé comme identifiant de communication dans une communication entre ce premier dispositif de communication et au moins un deuxième dispositif de communication, cet identifiant étant conforme à au moins un masque d'identifiant de communication accessible par au moins une entité intermédiaire placée sur au moins un chemin emprunté par des paquets de données de cette communication ; et - une étape d'envoi d'au moins un paquet de données comportant cet identifiant dans le cadre de cette communication.
Corrélativement, l'invention concerne un dispositif de communication comportant :
- un module de génération d'identifiants de communication configuré pour générer au moins un identifiant destiné à être utilisé comme identifiant de communication dans une communication entre ce dispositif de communication et au moins un deuxième dispositif de communication dans un réseau de communication, cet identifiant étant conforme à au moins un masque d'identifiant de communication accessible par au moins une entité intermédiaire placée sur au moins un chemin emprunté par des paquets de données de cette communication; et
- un module d'envoi de paquets de données configuré pour envoyer au moins un paquet de données comportant cet identifiant dans le cadre de cette communication.
Selon un troisième aspect, l'invention vise un système de communication comportant au moins :
- un dispositif de communication tel que mentionné ci-dessus, ce dispositif de communication étant configuré pour communiquer avec au moins un deuxième dispositif de communication ; et
- une entité intermédiaire telle que mentionnée ci-dessus configurée pour être placée sur au moins un chemin emprunté par les paquets de données d'une communication établie entre ces dispositifs de communication.
Ainsi, et d'une façon générale, l'entité intermédiaire conforme à l'invention, vérifie, pour gérer une communication établie entre deux dispositifs de communication, si un identifiant de communication véhiculé dans un paquet de cette communication est conforme ou non à un masque d'identifiant. Par exemple, dans un mode particulier de réalisation, l'entité intermédiaire vérifie si l'identifiant de communication est formé à partir d'au moins un masque d'identifiant de communication auquel elle peut accéder. Une telle entité intermédiaire est par exemple une entité se trouvant sur un chemin de la communication envisagée et apte à traiter des paquets de données échangés lors cette communication.
Le recours à un tel masque permet à l'entité intermédiaire de gérer une communication entre les dispositifs de communication en appliquant des traitements particuliers à au moins certains de ces paquets même si les identifiants de communication varient au cours de la communication. En effet, l'entité intermédiaire n'a pas besoin de mettre en œuvre une logique ou une structure qui établirait un historique ou un quelconque lien entre les identifiants de communication utilisés par les différents dispositifs au cours d'une même communication. Cette logique est remplacée par la simple vérification de la conformité de l'identifiant au masque.
Cette solution permet donc, en particulier et à moindre coût, de respecter les contraintes en matière de confidentialité du protocole QUIC telles que décrites précédemment.
L'invention n'impose en aucune façon à l'entité intermédiaire de procéder à une quelconque opération de chiffrement/déchiffrement, le rôle de cette entité étant essentiellement de vérifier la conformité d'un identifiant de communication à un ou plusieurs masques d'identifiant. Dans un mode particulier de réalisation, cette opération de vérification de ladite conformité peut consister essentiellement en une comparaison et peut être effectuée en réalisant un simple « ET » logique (opérande « AND » en anglais) entre l'identifiant et le masque.
On note en outre qu'avantageusement, les entités intermédiaires ne jouent pas un rôle de « proxy » pour la mise en œuvre de l'invention.
L'invention ne nécessite pas non plus l'introduction d'une entité de contrôle (qu'elle soit centralisée ou distribuée) dont le rôle serait d'informer les entités intermédiaires des modifications à venir des identifiants de communication (migration de connexion décrite précédemment). Les dispositifs de communication peuvent par conséquent modifier les identifiants de communication à tout moment, sans notification préalable à une entité externe. Ainsi, et de façon très avantageuse, l'invention ne complique pas l'ingénierie du réseau.
En particulier, les clefs cryptographiques utilisées par les dispositifs de communication pour chiffrer leurs communications ne sont pas communiquées aux entités intermédiaires : l'invention évite ainsi avantageusement d'introduire une faille sécuritaire liée à l'utilisation de ces entités intermédiaires.
Pour tous ces avantages notamment, l'invention permet d'améliorer la gestion des ressources du réseau et d'améliorer la qualité du service rendue et perçue par les utilisateurs.
Dans un mode particulier de mise en œuvre du procédé de communication selon l'invention, un identifiant de communication généré par un dispositif de communication peut être utilisé en tant qu'identifiant de communication source dans un paquet envoyé par ce dispositif de communication.
Dans un autre mode de réalisation du procédé de communication selon l'invention, le premier dispositif de communication envoie, au deuxième dispositif de communication avec lequel la communication a été établie, l'identifiant de communication chiffré dans un paquet de données. A la réception du paquet, le dispositif de communication distant utilise l'identifiant reçu en tant qu'identifiant de communication destination pour un paquet ultérieur de la communication.
Conformément à l'invention, le traitement d'un paquet de données tient compte de la conformité de l'identifiant de communication avec le masque d'identifiant de communication. Par exemple, tous les paquets reçus par l'entité intermédiaire, et dont l'identifiant de communication n'est pas conforme au masque (par exemple parce que l'identifiant n'a pas été formé à partir du masque d'identifiant de communication ad hoc) peuvent être bloqués.
Par exemple, dans un mode particulier de réalisation du procédé de gestion selon l'invention, l'entité intermédiaire met en œuvre une fonction pare-feu, et reçoit un masque d'un dispositif de communication dont elle gère la communication. L'étape de traitement d'un paquet de données comporte le filtrage de ce paquet en fonction de la conformité ou non de l'identifiant de communication selon par exemple qu'il a été formé ou non à partir du masque reçu de ce dispositif de communication. Dans ce mode de réalisation, le pare-feu peut par exemple communiquer une ou des consignes de génération de masques aux dispositifs de communication qu'il protège et recevoir, d'au moins un de ces dispositfs, un masque d'identifiant de communication généré à partir de ces consignes, le pare- feu pouvant être configuré pour bloquer les paquets entrants et/ou sortants qui véhiculent un 'identifiant de communication qui ne respecte pas un tel masque. Ce mode de réalisation de l'invention peut en particulier être mis en œuvre pour :
- filtrer les paquets reçus par un dispositif de communication, en vérifiant la conformité de l'identifiant de communication destination avec le masque; et/ou pour
- filtrer les paquets émis par un dispositif de communication en vérifiant la conformité de l'identifiant de communication source avec le masque.
Dans un mode de réalisation du procédé de gestion selon l'invention, l'entité intermédiaire reçoit le masque d'identifiant de communication en provenance d'un dispositif de communication et associe ce masque à ce dispositif de communication, et l'étape de traitement est en outre déterminée en fonction du dispositif de communication associé audit masque.
Dans un mode particulier de réalisation, le procédé de communication selon l'invention comporte :
- une étape de génération, par le premier dispositif de communication, d'au moins un masque d'identifiant de communication en appliquant au moins une consigne de génération de masques d'identifiants de communication ; et
- une étape d'enregistrement de ce masque auprès de l'entité intermédiaire.
Par exemple, dans une mise en œuvre de ce mode particulier de réalisation, le procédé de gestion selon l'invention comporte :
- une étape d'envoi d'un message d'annonce comportant au moins une consigne de génération de masques d'identifiants de communication ;
- le masque d'identifiant de communication étant reçu en provenance du dispositif de communication en réponse au message d'annonce.
Corrélativement, dans une mise en œuvre particulière, le procédé de communication selon l'invention comporte une étape de réception, par le premier dispositif de communication, d'un message d'annonce comportant au moins une consigne de génération de masques en provenance d'une entité intermédiaire.
Ce mode particulier de réalisation de l'invention est particulièrement avantageux lorsque l'entité intermédiaire met en œuvre une fonction d'acheminement de trafic (« forwarding » en anglais), ou une fonction de répartition de charge du trafic destiné à plusieurs dispositifs de communication, chacun de ces dispositifs de communication générant son propre masque d'identifiant de communication en appliquant la ou les consignes reçues. Dans ce mode de réalisation, le traitement d'un paquet par l'entité intermédiaire peut comporter la vérification qu'un identifiant de communication d'un paquet correspond à un masque d'un dispositif de communication donné puis l'acheminement de ce paquet vers ce dispositif de communication donné. Le message d'annonce peut par exemple être reçu en réponse à un message de découverte envoyé par le premier dispositif de communication.
Ce mode particulier de réalisation permet à une entité intermédiaire de s'annoncer dans le réseau et de communiquer sa ou ses consignes aux dispositifs de communication.
Dans un mode particulier de réalisation du procédé de gestion selon l'invention, ce message d'annonce comporte un identifiant de service qui identifie un service dont les paquets peuvent être traités par l'entité intermédiaire.
Une entité intermédiaire conforme à l'invention ne définit pas nécessairement elle-même la ou les consignes qu'elle utilise pour vérifier la conformité d'un identifiant de communication véhiculé par un paquet qu'elle traite.
Dans un mode particulier de réalisation dans lequel l'entité intermédiaire offre une fonction déterminée, le procédé de gestion selon l'invention peut comporter une étape de réception, en provenance d'au moins un dispositif de communication, d'au moins un masque d'identifiant de communication généré par ce dispositif de communication à partir d'au moins une consigne de génération de masques d'identifiants de communication fournie par une autre entité intermédiaire offrant cette fonction déterminée.
Par exemple, dans un mode particulier de mise en œuvre du procédé de communication selon l'invention, le premier dispositif de communication :
- détermine qu'une première entité intermédiaire offre la même fonction qu'une autre entité intermédiaire ; et
- enregistre auprès de cette première entité intermédiaire un masque d'identifiant de communication en application de ladite au moins une consigne de génération de masques utilisée par cette autre entité intermédiaire.
Ainsi, et de façon très avantageuse :
- les deux entités intermédiaires utilisent les mêmes masques d'identifiant de communication ;
- les paquets d'une même communication peuvent être acheminés vers un même dispositif de communication quelle que soit l'entité intermédiaire impliquée dans l'acheminement des paquets ; et
- le premier dispositif de communication utilise le même masque d'identifiant de communication pour communiquer avec les entités intermédiaires offrant la même fonction.
Ce mode de réalisation de l'invention est particulièrement avantageux car il permet à la première entité intermédiaire d'obtenir des masques générés en application de consigne(s) de génération fournie(s) par une autre entité intermédiaire sans qu'il n'y ait de communication préétablie entre ces entités intermédiaires.
Si la première entité intermédiaire reçoit, de plusieurs dispositifs de communication, une pluralité de masques d'identifiant de communication générés par ces dispositifs de communication selon la ou les consignes de génération de masques d'identifiants de communication fournies par une autre entité intermédiaire, cette première entité intermédiaire peut déduire la ou les consignes de génération de masques d'identifiants de communication de cette autre entité intermédiaire.
Ce mode de réalisation peut par exemple être mis en œuvre lorsqu'une deuxième entité intermédiaire est introduite pour remplacer une première entité intermédiaire. Dans ce cas-là, la deuxième entité intermédiaire peut simplement s'annoncer aux dispositifs de communication, lesquels enregistrent auprès d'elle des masques d'identifiants de communication en application de la ou des consignes qu'ils avaient reçues de la première entité intermédiaire.
Dans un mode particulier de réalisation de l'invention, le premier dispositif de communication peut générer un masque d'identifiant de communication et l'enregistrer auprès d'une entité intermédiaire sans recevoir la ou les consignes de cette entité intermédiaire.
Dans un mode particulier de réalisation, le procédé de gestion selon l'invention comporte :
- une étape de détection de conflit, un conflit étant détecté si un masque d'identifiant de communication reçu en provenance d'un dispositif de communication constituant une instance d'un service a déjà été associé par l'entité intermédiaire avec au moins un autre dispositif de communication constituant une instance différente du même service ; et
- une étape de déclenchement d'une modification dudit masque d'identifiant de communication par au moins un de ces dispositifs de communication.
Dans un mode particulier de réalisation, si l'entité intermédiaire reçoit d'un dispositif de communication une demande d'enregistrement d'un masque d'identifiant de communication déjà utilisé, elle peut rejeter cette demande d'enregistrement ou demander au dispositif de communication de lui proposer un nouveau masque.
Dans un mode particulier de réalisation, le premier dispositif de communication vérifie, avant d'enregistrer, auprès d'une première entité intermédiaire, pour un service déterminé, un masque généré en application d'une ou de premières consignes, qu'il n'a pas déjà enregistré auprès d'une autre intermédiaire, un masque pour le même service et généré en appliquant des consignes différentes. Ce mode de réalisation permet d'éviter des conflits de génération de masques et par conséquent d'identifiants de communication pour un même service.
Dans un mode particulier de réalisation, si le premier dispositif de communication détermine qu'il a déjà enregistré un masque pour le même service auprès d'une autre entité intermédiaire, il enregistre auprès de la première entité intermédiaire un masque généré selon ces autres consignes, de sorte à garantir la cohérence des masques.
Dans un mode particulier de réalisation, le procédé de gestion d'une communication selon l'invention comporte :
- une étape de vérification pour vérifier si l'entité intermédiaire peut traiter les paquets de données d'une communication impliquant le dispositif de communication en fonction :
(i) d'un nombre de dispositifs de communication déjà enregistrés par l'entité intermédiaire en association avec un masque d'identifiant de communication généré en application de ladite au moins une consigne de génération de masques; et
(ii) d'un nombre de bits définis par ladite au moins une consigne; et
- si ce n'est pas le cas, une étape d'envoi d'un message de renouvellement avec au moins une nouvelle consigne de génération de masques définissant un nombre supérieur de bits, ledit message de renouvellement demandant au dispositif de communication et aux dispositifs de communication déjà enregistrés de générer un nouveau masque d'identifiant de communication en appliquant ladite au moins une nouvelle consigne.
Ce mode de réalisation permet avantageusement à l'entité intermédiaire de procéder à la migration d'identifiants de communication pour pouvoir traiter plus de dispositifs de communication et éviter ainsi de rejeter les demandes d'enregisrement reçues des nouveaux dispositifs de communication.
Il est important de noter que l'entité intermédiaire selon l'invention ne génère pas elle-même les identifiants de communication. Tout au plus, elle définit des consignes, typiquement les bits qu'elle utilisera pour exécuter son service (par ex. vérifier la conformité d'identifiants de communication formés à partir d'un masque, traiter les paquets qu'elle achemine en fonction du masque). Ces bits sont les bits des identifiants de communication que l'entité intermédiaire considère comme « significatifs » car ce sont ceux qu'elle analyse pour déterminer si ils sont conformes ou non au(x) masque(s) d'identifiants qu'elle considère. Dans la suite de la description, on désigne ces bits par « bits significatifs » de l'identifiant de communication.
Les consignes de génération de masque d'un identifiant de communication définies dans l'invention permettent ainsi par exemple de déterminer la position et la valeur des bits significatifs de l'identifiant de communication.
Par exemple ces consignes peuvent comporter :
- des entiers permettant d'obtenir la position des premier et dernier bits significatifs d'une séquence de bits comportant les bits significatifs dudit identifiant de communication ; et
- un entier optionnel indiquant les positions des bits significatifs dudit identifiant de communication au sein de ladite séquence.
Dans un mode de réalisation de l'invention, ladite au moins une consigne de génération d'un masque comporte au moins une information parmi :
- une information représentative d'une position d'un premier bit d'un identifiant de communication correspondant à un masque de cet identifiant ;
- une information représentative d'une position d'un dernier bit de cet identifiant de communication correspondant à ce masque; et
- une information représentative des positions ou d'un nombre de bits de cet identifiant de communication correspondant à ce masque. Dans un mode particulier de réalisation, la communication entre le premier dispositif de communication et le deuxième dispositif de communication est conforme à un protocole de communication reposant sur le protocole de transport UDP, par exemple le protocole QUIC.
On rappelle que le protocole QUIC est un protocole de transport qui repose sur le protocole UDP (User Datagram Protocol) et dont la conception et l'utilisation ont notamment pour objectif de réduire les temps de latence généralement observés lors de l'établissement de connexions TCP (Transmission Control Protocol). Pour plus de renseignements sur le protocole QUIC, l'homme du métier peut se reporter au document « Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed and Secure Transport", draft-ietf-quic-transport (work in progress), 2019 ».
Toutefois, le protocole QUIC est cité à titre d'exemple, et l'invention peut s'appliquer également à d'autres protocoles, notamment d'autres protocoles reposant sur le protocole UDP, avec une application privilégiée dans le cadre de protocoles mettant en œuvre, comme QUIC, un chiffrement des données utiles et de certaines informations de contrôle de la communication.
L'invention vise également un programme d'ordinateur sur un support d'enregistrement, ce programme étant susceptible d'être mis en œuvre dans un ordinateur. Ce premier programme comporte des instructions adaptées à la mise en œuvre d'un procédé de gestion de communication tel que décrit ci-dessus.
L'invention vise également un programme d'ordinateur sur un support d'enregistrement, ce programme étant susceptible d'être mis en œuvre dans un ordinateur. Ce deuxième programme comporte des instructions adaptées à la mise en œuvre d'un procédé de communication tel que décrit ci-dessus.
Chacun de ces programmes peut utiliser n'importe quel langage de programmation, et être sous la forme de code source, code objet, ou de code intermédiaire entre code source et code objet, tel que dans une forme partiellement compilée, ou dans n'importe quelle autre forme souhaitable.
L'invention vise aussi un support d'information ou un support d'enregistrement lisibles par un ordinateur, et comportant des instructions du premier ou du deuxième programme d'ordinateur tel que mentionné ci-dessus.
Les supports d'information ou d'enregistrement peuvent être n'importe quelle entité ou dispositif capable de stocker les programmes. Par exemple, les supports peuvent comporter un moyen de stockage, tel qu'une ROM, par exemple un CD ROM ou une ROM de circuit microélectronique, ou encore un moyen d'enregistrement magnétique, par exemple une disquette (floppy dise) ou un disque dur, ou une mémoire flash.
D'autre part, les supports d'information ou d'enregistrement peuvent être des supports transmissibles tels qu'un signal électrique ou optique, qui peut être acheminé via un câble électrique ou optique, par lien radio, par lien optique sans fil ou par d'autres moyens. Les programmes selon l'invention peuvent être en particulier téléchargés sur un réseau de type Internet.
Alternativement, chaque support d'informations ou d'enregistrement peut être un circuit intégré dans lequel un programme est incorporé, le circuit étant adapté pour exécuter ou pour être utilisé dans l'exécution de l'un des procédés conformes à l'invention.
Brève description des dessins
D'autres caractéristiques et avantages de la présente invention ressortiront de la description faite ci- dessous, en référence aux dessins annexés qui en illustrent un exemple de réalisation dépourvu de tout caractère limitatif. Sur les figures :
[Fig. 1] la figure 1 représente une communication QUIC conforme à l'état actuel de la technique ;
[Fig. 2] la figure 2 représente un paquet QUIC conformément à l'état actuel de la technique ;
[Fig. 3] la figure 3 représente une communication QUIC entre deux dispositifs de communication conformément à l'état actuel de la technique ;
[Fig. 4] la figure 4 illustre un mécanisme de découverte pouvant être mis en œuvre dans un mode particulier de réalisation de l'invention ;
[Fig. 5] la figure 5 représente un message d'annonce pouvant être utilisé dans un mode particulier de réalisation de l'invention ;
[Fig. 6] la figure 6 représente une table d'instances d'entités intermédiaires pouvant être utilisée dans un mode particulier de réalisation de l'invention ;
[Fig. 7] la figure 7 représente un message d'enregistrement pouvant être utilisé dans un mode particulier de réalisation de l'invention ;
[Fig. 8] la figure 8 représente une table d'instances de dispositifs de communication pouvant être utilisée dans un mode particulier de réalisation de l'invention ;
[Fig. 9] la figure 9 représente un format d'une consigne de génération de masques pouvant être utilisé dans un mode particulier de réalisation de l'invention ;
[Fig. 10] les figures 10A à 10E représentent des exemples de consignes conformes au format de la figure 9 ;
[Fig. 11] la figure 11 illustre des étapes d'un procédé de gestion d'une communication conforme à un mode particulier de réalisation de l'invention ;
[Fig. 12] la figure 12 représente une table de dispositifs de communication utilisée dans un exemple de mise en œuvre de l'invention ;
[Fig. 13] la figure 13 représente un processus pouvant être mis en œuvre pour l'activation d'une entité intermédiaire dans un mode particulier de réalisation de l'invention ; [Fig. 14] la figure 14 illustre un mécanisme pouvant être mis en œuvre par un dispositif de communication conforme à un mode particulier de réalisation de l'invention pour optimiser le traitement du trafic lorsqu'il reçoit des paquets de plusieurs entités intermédiaires conformes à l'invention ;
[Fig. 15] la figure 15 illustre un processus pouvant être mis en œuvre dans l'invention pour retirer une entité intermédiaire ;
[Fig. 16] la figure 16 illustre un exemple de mise à jour d'une table d'instances de service dans un mode particulier de mise en œuvre de l'invention ;
[Fig. 17] la figure 17 illustre un premier exemple pour remplacer une entité intermédiaire par une autre dans un mode particulier de réalisation de l'invention ;
[Fig. 18] la figure 18 illustre un deuxième exemple pour remplacer une entité intermédiaire par une autre dans un autre mode particulier de réalisation de l'invention ;
[Fig. 19] la figure 19 illustre un exemple pour remplacer un dispositif de communication par un autre dans un autre mode particulier de réalisation de l'invention ;
[Fig. 20] la figure 20 représente un processus de renouvellement d'un masque d'identifiant de communication à l'initiative d'un dispositif de communication conformément à un mode particulier de réalisation de l'invention ;
[Fig. 21] la figure 21 illustre la mise à jour d'une table de dispositifs de communication dans un mode particulier de réalisation de l'invention suite à une modification d'un masque d'identifiant de communication ;
[Fig. 22] la figure 22 représente un processus de renouvellement d'un masque d'identifiant de communication à l'initiative d'une entité intermédiaire dans un mode particulier de réalisation de l'invention;
[Fig. 23] la figure 23 représente un processus d'introduction d'un nouveau dispositif de communication conformément à un mode particulier de réalisation de l'invention;
[Figure 24] la figure 24 illustre un mode particulier de mise en œuvre de l'invention dans lequel l'entité intermédiaire est un pare-feu ;
[Figure 25] la figure 25 illustre une table de dispositifs de communication pouvant être utilisée dans le contexte du mode de réalisation de la figure 24 ;
[Figure 26] la figure 26 représente l'architecture matérielle d'une entité intermédiaire conforme à un mode particulier de réalisation de l'invention ;
[Figure 27] la figure 27 représente l'architecture matérielle d'un dispositif de communication conforme à un mode particulier de réalisation de l'invention ; et [Figure 28] la figure 28 représente un système conforme à un mode particulier de réalisation de l'invention.
Description détaillée de plusieurs modes de réalisation de l'invention
L'invention est décrite à présent dans le contexte particulier dans lequel les dispositifs de communication établissent une communication selon le protocole QUIC.
La présente invention vise notamment un procédé de gestion d'une communication et un procédé de communication. Dans la présente demande, une « communication » entre deux équipements désigne l'ensemble des échanges entre l'établissement, la maintenance et la terminaison de cette communication.
Dans le contexte particulier du protocole QUIC, une communication au sens de l'invention est également appelée « connexion ». Par conséquent, si le mot connexion est utilisé dans la suite de la description, il désigne une communication au sens de l'invention. Ainsi, un « identifiant de connexion » dans le contexte particulier du protocole QUIC est un identifiant de communication au sens de l'invention. Corrélativement, lorsque dans la suite de la description on fait référence à un identifiant de communication dans le cadre du protocole QUIC, il s'agit d'un identifiant de connexion (ou CID pour « Connection Identifier » en anglais) au sens du protocole QUIC.
La figure 1 représente une connexion (ou communication) QUIC CQ entre deux dispositifs de communication PTi et PT2. Une communication QUIC permet de multiplexer différents canaux de communication G (en anglais « streams ») dans lesquels des paquets P de données sont acheminés. Les dispositifs de communication PTi et PT2 peuvent par exemple être un terminal (référencé ci-après PTUT), un client (référencé PTCT) OU une instance de service (référencée PTis). L'un ou l'autre des dispositifs de communication peut établir un canal de communication G. Le dispositif de communication qui est à l'origine de l'établissement d'un canal est appelé « source » et sera référencé PTso ; l'autre dispositif de communication avec lequel ce canal est établi est appelé « destination » et sera référencé PTDE. Sur une figure, un même dispositif de communication pourra avoir plusieurs références, par exemple PTis et PTso pour un dispositif de communication source de type instance de service.
Un paquet P QUIC, représenté sur la figure 2 comporte un en-tête public ETP et des données utiles DU. Dans un tel paquet, les données utiles DU sont chiffrées, et incluent les informations de contrôle de communication. Un paquet QUIC comporte un en-tête public ETP comportant lui-même, des drapeaux (flags FL), un identifiant de communication (ou « identifiant de connexion » comme indiqué ci-dessus) et un numéro de paquet PN. L'identifiant de communication est envoyé en clair. L'identifiant d'un canal de communication G, non représenté dans la figure 2, est chiffré. L'identifiant de connexion QUIC est un exemple d'identifiant de communication décrit précédemment. La spécification QUIC distingue l'identifiant de communication associé à la source (et désigné « SCID » pour « Source Connection Identifier ») de l'identifiant de communication associé à la destination (et désigné « DCID » pour « Destination Connection Identifier »).
Le paquet de la figure 2 est un paquet QUIC avec un en-tête ETP court. Dans de tels paquets, l'en tête public ETP ne comporte que l'identifiant de communication de la destination, soit le DCID. La spécification QUIC définit également un en-tête long comportant l'identifiant de communication de la destination DCID et l'identifiant de communication de la source SCID.
On note qu'il est usuel pour l'homme du métier de désigner par « identifiant de communication CID,
« Connection IDentifier » en anglais) » le couple {DCID, SCID}. Par abus de langage, on dit parfois que l'identifiant de communication CID comporte deux parties, une partie source SCID et une partie destination DCID. Dans la description de l'invention, la notion d'identifiant de communication (ou d'identifiant de connexion) inclut donc aussi bien le couple {DCID, SCID} que chacun des identifiants DCID et SCID indépendamment.
La figure 3 représente une communication QUIC établie entre deux dispositifs de communication PTi et PT2, une entité intermédiaire El placée sur le chemin emprunté par les paquets caractéristiques de cette communication et un paquet QUIC P de cette communication tel que vu par l'entité intermédiaire EL Pour cette entité intermédiaire El, toutes les données du paquet QUIC (représentées hachurées) sont chiffrées, à l'exception de l'identifiant de communication SCID ou DCID (dans l'exemple d'un en-tête ETP court). Au sens du protocole QUIC, une communication est identifiée par :
- le quadruplet constitué par l'adresse IP source et le numéro de port source du dispositif de communication source et l'adresse IP destination et le numéro de port destination du dispositif de communication destinataire du paquet ; et par
- l'identifiant de communication SCID ou DCID.
Dans la description de cette présente demande on désigne par @E le couple {adresse IP, numéro de port} d'un équipement ou d'une fonction E.
Certaines figures seront décrites dans des modes de réalisation particuliers dans lesquels les entités intermédiaires mettent en œuvre une fonction de répartition de charge de trafic ou une fonction pare- feu. Ces entités intermédiaires pourront alors être simplement désignées « répartiteur de charge »
(en anglais « load balancer ») ou « pare-feu » (en anglais « firewall ») et référencées respectivement EILB OU EIFW.
Dans la description ci-après, les étapes références EXX sont mises en œuvre par un dispositif de communication et les étapes référencées FXX sont mises en œuvre par une entité intermédiaire.
La figure 3 illustre aussi qu'un dispositif de communication peut fournir plusieurs services par exemple servi, serv2, serv3, .... Dans la suite de la description on désignera par servjd, l'identifiant désignant un tel service. La figure 4 illustre comment, dans un mode particulier de mise en œuvre de l'invention, un dispositif de communication PT conforme à l'invention peut :
- découvrir des entités intermédiaires El conformes à l'invention ;
- générer un ou plusieurs masques d'identifiants de communication en application d'une ou de consignes de génération de masque reçues d'une entité intermédiaire. Dans l'exemple envisagé ici, on considère une pluralité de consignes de génération de masques, toutefois l'invention peut s'appliquer également dans un contexte où une seule consigne de génération de masque est reçue de l'entité intermédiaire ; et
- demander à cette entité d'intermédiaire El d'enregistrer un ou plusieurs de ces masques en l'absence de détection de conflit.
Dans la figure 4, on se place dans le contexte d'un réseau comportant un dispositif de communication PT et deux entités intermédiaires, à savoir un pare-feu EIFW et un répartiteur de charge EILB.
Dans le mode de réalisation décrit ici, au cours d'une étape E0400, le dispositif de communication PT conforme à l'invention envoie un message de découverte QUERY pour détecter d'éventuelles entités intermédiaires El conformes à l'invention.
Dans le mode de réalisation décrit ici, le message de découverte QUERY est envoyé à une adresse de diffusion ADDR_S écoutée par tous les entités intermédiaires EL
Si le dispositif de communication ne cherche à découvrir que des entités intermédiaires mettant en œuvre une fonction déterminée (par exemple une fonction de répartition de charge), le message de découverte QUERY comporte une clause de service fnjd identifiant cette fonction de répartition de charge de trafic. Cette clause est optionnelle.
On suppose que les entités intermédiaires El écoutent sur l'adresse de diffusion ADDR_S vers laquelle les dispositifs de communication PT envoient les messages de découverte QUERY.
Au cours d'une étape F0400, les entités intermédiaires El reçoivent le message de découverte QUERY.
Dans le mode de réalisation décrit ici :
- toutes les entités intermédiaires El qui reçoivent le message de découverte QUERY y répondent si ce message ne comporte pas de clause de service ; et
- lorsque le message de découverte QUERY comporte une telle clause, seules les entités intermédiaires El mettant en œuvre la fonction identifiée par cette clause, y répondent.
Dans le mode de réalisation décrit ici, pour répondre au message de découverte QUERY et annoncer sa présence aux dispositifs de communication PT, une entité intermédiaire El envoie, au cours d'une étape F0410, un message d'annonce ANNOUNCE à une adresse broadcast ou à une adresse multicast réservée à cet usage ADDR_L, l'adresse source de ce message étant une adresse IP unicast @EI de l'entité intermédiaire EI.
Pour simplifier la figure 4, on a représenté un cas où seul le répartiteur de charge EILB répond, par l'envoi d'un message ANNOUNCE, au message de découverte QUERY.
La figure 5 représente un message d'annonce ANNOUNCE pouvant être utilisé dans l'invention.
Dans le mode de réalisation décrit ici, le message d'annonce ANNOUNCE peut comporter un identifiant IDEI de l'entité intermédiaire El (par exemple son adresse IP @EI), un identifiant fnjd de la fonction mise en œuvre par cette entité intermédiaire (par exemple fonction répartiteur de charge, fonction pare-feu ,...) et un ou plusieurs identifiants servjd des services du dispositif de communication PT auxquels l'entité intermédiaire El est autorisée à offrir sa fonction (par exemple sa fonction de répartition de charge ou sa fonction pare-feu).
Ces identifiants de service peuvent être définis par un administrateur d'un réseau qui héberge des dispositifs de communication conformes à l'invention et fournissant ces services. Par exemple, si l'entité intermédiaire El offre une fonction de répartition de charge de trafic, les messages d'annonce ANNOUNCE envoyés par cette entité intermédiaire peuvent comporter des identifiants des services dont la charge peut être répartie par cette entité. Ces identifiants de service peuvent être structurés sous forme d'un alias, un FQDN (en anglais Fully Qualified Domain Name), etc.
Le message d'annonce ANNOUNCE peut également comporter une ou des consignes de génération de masques DG_MASK permettant à un dispositif de communication de créer un ou plusieurs de ces masques d'identifiants de communication en application de ces consignes. Selon les scénarios de mise en œuvre de l'invention, les identifiants de communication créés à partir de ce masque peuvent être des identifiants de communication source SCID et/ou des identifiants de communication de destination DCID.
En envoyant ses consignes pour la génération de masques aux dispositifs de communication, l'entité intermédiaire s'attend à ce que ces dispositifs de communication génèrent des masques d'identifiant de communication en application de ces consignes puis qu'ils les enregistrent auprès d'elle.
Ces consignes sont destinées à être utilisées par l'entité intermédiaire pour, lorsqu'elle intercepte un paquet, déterminer le masque de l'identifiant de communication SCID ou DCID véhiculé dans ce paquet à partir de cet identifiant de communication et pour vérifier si cet identifiant est conforme au masque d'identifiant ainsi déterminé.
Un exemple de format de consigne DG_MASK sera décrit en référence à la figure 9 et des exemples de consignes utilisant ce format seront décrits en référence aux figures 10A à 10E.
Dans le mode de réalisation décrit ici, le message d'annonce ANNOUNCE peut comporter un champ « mode de diffusion » MD (en anglais « broadcast mode ») qui définit comment un dispositif de communication PT doit répondre à ce message d'annonce. Dans le mode de réalisation décrit ici, le mode de diffusion MD peut prendre deux valeurs qui définissent si le dispositif de communication PT doit répondre à ce message en utilisant l'adresse de diffusion ADDR_S utilisée à l'étape E0400 ou en utilisant une adresse unicast @EI de l'entité intermédiaire.
Dans le mode de réalisation décrit ici, le message d'annonce ANNOUNCE comporte un paramètre définissant si l'entité intermédiaire El réécrit ou non l'adresse des paquets qu'elle relaye vers un dispositif de communication PT.
En référence à la figure 4, le dispositif de communication PT reçoit le message d'annonce ANNOUNCE annonçant la présence de l'entité intermédiaire EILB au cours d'une étape E0410.
Si le message d'annonce ANNOUNCE comporte un identifiant fnjd d'une fonction qui ne correspond pas à celle recherchée par le dispositif de communication PT, le dispositif de communication PT ignore le message d'annonce ANNOUNCE. On suppose dans l'exemple de la figure 4 que ce n'est pas le cas.
Dans le mode de réalisation décrit ici, au cours d'une étape E0420, le dispositif de communication PT enregistre un identifiant IDEI de l'entité intermédiaire EILB dans une table d'instances d'entités intermédiaires notée EI_INST et représentée par la figure 6. Dans le mode de réalisation décrit ici, le dispositif de communication PT y enregistre en outre l'adresse @EI de l'entité intermédiaire et d'autres informations non représentées, par exemple un contexte de sécurité et un horodatage du dernier message reçu de cette entité intermédiaire. L'identifiant IDEI de l'entité intermédiaire peut être généré localement par le dispositif de communication PT sur la base des informations véhiculées dans le message d'annonce ANNOUNCE. Les dispositifs de communication PT peuvent utiliser localement des identifiants IDEI différents pour identifier une même entité intermédiaire EL
Au cours d'une étape E0430, le dispositif de communication PT génère au moins un masque d'identifiant de communication CID_MASKEi en application une ou des consignes de génération de masque DG_MASKEI.
Ce masque d'identifiant de communication est destiné à être utilisé par le dispositif de communication PT pour ses communications impliquant l'entité intermédiaire EILB. Dans le mode de réalisation décrit ici, ce masque est également destiné à être utilisé par le dispositif de communication PT pour ses communications impliquant une ou plusieurs autres entités intermédiaires offrant la même fonction (répartition de charge de trafic) que l'entité intermédiaire EILB.
Par conséquent, le dispositif de communication PT enregistre le masque d'identifiant de communication CID_MASKEI dans la table d'instances d'entités intermédiaires EI_INST en association avec l'entité intermédiaire EILB et en association avec les autres entités intermédiaires offrant la fonction de répartition de charge de trafic.
Dans le mode de réalisation décrit ici, ce masque est initialement associé dans la table EI_INST à un état OFF représentant le fait qu'il n'a pas encore été accepté par l'entité intermédiaire EL Dans le mode de réalisation décrit ici, l'état associé à un masque d'identifiant de communication dans une table d'instances d'entités intermédiaires EI_INST gérée par un dispositif de communication peut prendre trois valeurs, à savoir :
- l'état « OFF » représentant le fait que le masque n'est pas encore utilisé ou n'est plus utilisé par le dispositif de communication par exemple parce qu'il n'a pas été accepté par l'entité intermédiaire EL Lorsque le masque est associé à l'état OFF, on dit aussi que ce masque est « inactif » ;
- l'état « ON » si le masque est effectivement utilisé par le dispositif de communication ; et
- l'état de fin d'activité « OBT » (pour l'expression anglaise « On But Terminating ») indiquant que le masque est actif mais destiné à devenir inactif par exemple après une échéance déterminée ou après la terminaison de la dernière communication active entre le dispositif de communication et l'entité intermédiaire concernée.
Dans le mode de réalisation décrit ici, la table d'instances d'entités intermédiaires EI_INST mémorise également les identifiants servjd des services fournis par des dispositifs de communication qui peuvent être accédés selon l'exécution de la fonction offerte par l'entité intermédiaire (répartition de charge de trafic, pare-feu, ...).
Au cours d'une étape E0440, le dispositif de communication PT envoie selon un mode unicast (ou diffuse) un message d'enregistrement REGISTER comportant le masque d'identifiant de communication CID_MASKEI pour enregistrer ce masque auprès de l'entité intermédiaire El, à savoir ici auprès du répartiteur de charge EILB. Ce message peut comporter un identifiant de service servjd correspondant au service fourni le cas échéant par le dispositif de communication PT.
Dans le mode de réalisation décrit ici, le dispositif de communication envoie selon un mode unicast (ou diffuse) le message d'enregistrement REGISTER conformément au mode de diffusion MD compris dans le message d'annonce ANNOUNCE reçu à l'étape E0410 : l'adresse de destination est soit l'adresse IP unicast @EI de l'entité intermédiaire EILB soit l'adresse de diffusion ADDR_S- L'adresse source du message REGISTER est une adresse IP unicast @PT affectée au dispositif de communication. Ce message d'enregistrement REGISTER peut être envoyé plusieurs fois pour rafraîchir l'enregistrement du masque d'identifiant de communication CID_MASKEI auprès des entités intermédiaires El concernées, ici, auprès du répartiteur de charge EILB.
Dans le mode de réalisation décrit ici, le message d'enregistrement REGISTER comporte en outre un identifiant IDPT du dispositif de communication PT.
Dans un mode de réalisation de l'invention et comme représenté à la figure 7, l'identifiant du dispositif de communication utilisé dans le message d'entregistrement REGISTER est l'adresse IP (et le port) @PT utilisée par ledit dispositif de communication.
Cet identifiant peut également être un alias, un nom de domaine, etc. L'identifiant utilisé par une entité intérmédiaire pour identifier un dispositif de communication est une décision locale à l'éntité. Dans un autre mode particulier de réalisation de l'invention, si un tunnel sécurisé, par exemple de type TLS (« Transport Layer Security » en anglais), est utilisé pour l'envoi du message d'enregistrement REGISTER, cet identifiant peut être le champ DNS-ID du Message ClientHello.
Le message d'enregistrement REGISTER est reçu par une ou plusieurs entités intermédiaires El au cours d'une étape F0440 ; cette entité intermédiaire El enregistre l'identifiant du dispositif de communication PT dans une table d'instances de dispositifs de communication PT_INST dont un exemple est illustré par la figure 8.
Dans le mode de réalisation décrit ici, l'entité intermédiaire El enregistre également dans la table d'instances de dispositifs de communication PT_INST une adresse IP @PT du dispositif de communication PT. Elle peut aussi y enregistrer une adresse MAC du dispositif de communication ainsi qu'un contexte de sécurité ; ces dernières informations ne sont pas représentées dans la table PT_INST de la figure 8.
Dans le mode de réalisation décrit ici, si le dispositif de communication PT est une instance PTis d'un service déterminé, l'entité intermédiaire El vérifie, au cours d'une étape F0450, si le masque d'identifiant de communication CID_MASKEI reçu à l'étape F0440 est identique à un masque d'identifiant de communication déjà reçu pour une autre instance du même service. Cette situation constitue un conflit au sens de l'invention.
Dans le mode de réalisation décrit ici, si l'entité intermédiaire détecte un tel conflit, elle envoie, au cours d'une étape F0460 un message CONFLICT de signalement de conflit au dispositif de communication PTis. Sinon elle enregistre le masque d'identifiant de communication CID_MASKEI dans la table d'instances de dispositifs de communication PT_INST en association avec un état ON représentatif de l'utilisation de ce masque par le dispositif de communication PTis et envoie un accusé de réception (acquittement, ACK pour « acknowledgment » en anglais) à ce dispositif de communication PTis.
Dans le mode de réalisation décrit ici, l'état associé à un masque d'identifiant de communication dans une table d'instances de dispositifs de communication PT_INST gérée par une entité intermédiaire El peut prendre trois valeurs, à savoir :
- l'état « ON » si le masque est actif, c'est-à-dire en cours d'utilisation par le dispositif de communication ;
- l'état « OFF » si le masque est inactif, par exemple parce qu'il n'a pas été accepté par l'entité intermédiaire El ;
- l'état de fin d'activité « OBT » indiquant que le masque est actif mais qu'il va devenir inactif par exemple après une échéance déterminée ou après la terminaison de la dernière communication active entre cette entité intermédiaire et le dispositif de communication.
En pratique, dans le mode de réalisation décrit ici, une entité intermédiaire El détecte un conflit si elle identifie dans sa table d'instances de dispositifs de communication PT_INST, deux enregistrements comportant un même masque d'identifiant de communication à l'état ON associé à deux instances différentes d'un même service.
Le message CONFLICT de signalement de conflit ou l'accusé de réception positif ACK est reçu par le dispositif de communication au cours d'une étape E0460.
Si le dispositif de communication reçoit un message CONFLICT de signalement de conflit, le dispositif de communication PT exécute à nouveau :
- l'étape E0430 pour générer au moins un autre masque d'identifiant de communication CID_MASKEI2 en utilisant les consignes de génération de masque DG_MASKEI, puis pour enregistrer ce nouveau masque d'identifiant de communication CID_MASKEI2 dans la table d'instances d'entités intermédiaires EIJNST ; et
- l'étape E0440 pour envoyer un message d'enregistrement REGISTER comportant le nouveau masque d'identifiant de communication CID_MASKEI2 pour l'enregistrer auprès de l'entité intermédiaire EI.
Cette procédure peut être réitérée plusieurs fois, jusqu'à ce que l'entité intermédiaire El considère que le masque d'identifiant de communication CID_MASKEI2 reçu du dispositif de communication PT à l'étape F0440 n'est pas en conflit avec un masque d'identifiant de communication utilisé par un autre point de terminaison.
Dans le mode de réalisation décrit ici, si le dispositif de communication PT reçoit à l'étape E0460 un message d'acquittement ACK, il considère que le masque d'identifiant de communication CID_MASKEI est confirmé et il modifie son état à ON dans sa table EI_INST d'instances d'entités intermédiaires.
La figure 9 représente un format de consignes de génération de masques DG_MASK pouvant être fournies par une entité intermédiaire El à un dispositif de communication PT pour lui permettre de générer un masque d'identifiant de communication à partir duquel il pourra générer des identifiants de communication .
Dans le mode de réalisation décrit ici, ces consignes DG_MASKEI peuvent comporter :
- une information représentative d'une position d'un premier bit d'un identifiant de communication formé à partir d'un masque de cet identifiant ;
- une information représentative d'une position d'un dernier bit de cet identifiant de communication correspondant à ce masque; et
- une information représentative des positions ou d'un nombre de bits de cet identifiant de communication correspondant à ce masque.
Dans les exemples ci-après, les entiers optionnels suivants peuvent être utilisés :
(i) nb_sb : entier indiquant le nombre de bits « significatifs » de l'identifiant de communication, c'est- à-dire, comme mentionné précédemment, ceux qu'il convient de considérer pour vérifier la conformité de l'identifiant au masque ;
(ii) offset_sb : entier indiquant le décalage du premier bit significatif de l'identifiant de communication (iii) demux_sb : entier indiquant la position des bits significatifs de l'identifiant de communication.
La figure 10A fournit un exemple dans lequel le décalage offset_sb n'est pas fourni, le nombre nb_sb de bits significatifs est égal à 32 et l'entier demux_sb n'est pas fourni : les bits significatifs du masque sont les 32 premiers bits d'un identifiant de communication. Dans cet exemple, le dispositif de communication peut ainsi choisir un masque parmi les valeurs comprises entre « 0 » et «
4294967295 », soit 232 valeurs. La valeur choisie par un dispositif de communication sera positionnée dans les 32 premiers bits de tous les identifiants de communication choisis par ce dispositif de communication.
La figure 10B fournit un exemple dans lequel le décalage offset_sb est égal à 32, le nombre nb_sb est égal à 32 alors que l'entier demux_sb n'est pas fourni : les bits significatifs sont les bits de position 33 à 64 d'un identifiant de communication. Dans cet exemple, le dispositif de communication peut ainsi choisir un masque parmi les valeurs comprises entre « 0 » et « 4294967295 », soit 232 valeurs. La valeur choisie par un dispositif de communication sera toujours positionnée dans les bits 33 à 64 de tous les identifiants de communication choisis par ce dispositif de communication.
La figure 10C fournit un exemple dans lequel le décalage offset_sb est égal à 48, le nombre nb_sb de bits significatifs est égal à 16 alors que l'entier demux_sb n'est pas fourni : les bits significatifs sont les bits de position 49 à 64 d'un identifiant de communication. Dans cet exemple, le dispositif de communication peut ainsi choisir un masque parmi les valeurs comprises entre « 0 » et « 65535 », soit 216 valeurs. La valeur choisie par un dispositif de communication sera toujours positionnée dans les bits 49 à 64 de tous les identifiants de communication choisis par ce dispositif de communication.
La figure 10D fournit un exemple dans lequel le décalage offset_sb est égal à 32, le nombre nb_sb de bits significatifs est égal à 32, et l'entier demux_sb est égal à 1897 (à savoir la valeur binaire 00000....11101101001) : les bits significatifs sont les bits 54, 55, 56, 58, 59, 61 et 64 d'un identifiant de communication. Dans cet exemple, le dispositif de communication peut ainsi choisir un masque parmi les 128 valeurs possibles en respectant la position des 7 bits significatifs, par exemple 1793, 1856, 1889, 18896, ...
La figure 10E fournit un exemple dans lequel le décalage offset_sb n'est pas fourni, le nombre nb_sb de bits significatifs est égal à 32 et l'entier demux_sb est égal à 789 (à savoir la valeur binaire 0000000....1100010101) : les bits significatifs sont les bits 23, 24, 28, 30 et 32 d'un identifiant de communication. Dans cet exemple, le dispositif de communication peut ainsi choisir un masque parmi les 32 valeurs possibles en respectant la position des 5 bits significatifs, par exemple 21, 533, 722, 788, ...
De même, on peut utiliser une position last_sb du dernier bit significatif au lieu de l'entier demux_sb.
La figure 11 illustre des étapes d'un procédé de gestion d'une communication conforme à un mode de réalisation de l'invention. Pour décrire cette figure on reprend l'exemple de la figure 10E, et on considère qu'une entité intermédiaire El envoie au cours d'une étape Fl 100 un message d'annonce ANNOUNCE avec des consignes de génération de masques DG_MASK dans lesquelles le décalage offset_sb n'est pas fourni, le nombre nb_sb de bits significatifs est égal à 32 et l'entier demux_sb est égal à 789.
On suppose qu'un premier dispositif de communication PTi reçoit ce message d'annonce (étape El 100), génère un masque 21 en application des consignes DG_MASK, et demande l'enregistrement de ce masque 21 par l'entité intermédiaire El à l'étape E1102.
On suppose également qu'un deuxième dispositif de communication PT2 reçoit ce message d'annonce (étape El 103), génère le masque 533 en application des consignes DG_MASK et demande l'enregistrement de ce masque 533 par l'entité intermédiaire EILB à l'étape El 104.
L'entité intermédiaire El enregistre au cours d'une étape Fl 105 ces masques dans sa table d'instances de dispositifs de communication PT_INST, celle-ci étant représentée par la figure 12.
On suppose que le premier dispositif de communication PTi génère, au cours d'une étape El 106, un identifiant de communication égal à 16415 et utilise cet identifiant en tant qu'identifiant de communication source SCID pour communiquer avec un dispositif de communication PTCT, cet identifiant de communication SCID étant effectivement conforme car formé à partir du masque 21.
On suppose que ce dispositif de communication PTCT envoie, à l'étape E1107 au premier dispositif de communication PTi, un paquet de données comportant comme identifiant de communication destination DCID la valeur 16415.
Dans cet exemple, l'entité intermédiaire El intercepte ce paquet à l'étape Fl 107 et vérifie si l'identifiant de communication DCID véhiculé en clair dans ce paquet est conforme, c'est-à-dire formé (ou encore produit ou généré) à partir d'un masque enregistré dans sa table d'instances de dispositifs de communication PT_INST.
A cet effet, dans cet exemple, l'entité intermlédiaire El applique les consignes de génération de masques DG_MASKEI (paramètres offset_sb non défini, nb_sb=32, demux_sb=789) pour extraire le masque de l'identifiant à partir de l'identifiant 16415, comme illustré ci-dessous:
16415 (32 bits) = 00000000000000001000000000011111 ;
789 = 00000000000000000000001100010101
Elle en déduit (opérande « ET ») dans cet exemple la valeur 21 (10101) du masque et, en consultant sa table d'instances PT_INST, que ce paquet est destiné au premier dispositif de communication PT1. Elle envoie donc ce paquet au premier dispositif de communication PT1.
Par conséquent, une fois que l'entité intermédiaire El a construit sa table PT_INST d'instances de dispositifs de communication, elle peut traiter les communications reçues et les diriger vers les différents dispositifs de communication RTi, PT2. L'invention est particulièrement avantageuse lorsque l'entité intermédiaire El est un répartiteur de charge EILB et les dispositifs de communication des instances PTisi, PTis2 d'un même service. En effet, quand une nouvelle communication est interceptée par cette entité intermédiaire répartiteur de charge, typiquement avec un identifiant de communication destination DCID égal à 0, celle-ci sélectionne une instance de service PTisi ou PTis2 en fonction d'un algorithme de répartition de charge de trafic avec lequel elle a été configurée. La communication est alors établie avec l'instance sélectionnée. Cette instance de service sélectionne un identifiant de communication qu'elle transmet au dispositif de communication distant PTCT en tant qu'identifiant de communication source SCID, cet identifiant étant conforme parce que formé à partir du masque généré en application des consignes de génération de masque DG_MASKEI reçues du répartiteur de charge.
Le répartiteur de charge EILB n'a pas besoin de maintenir un état pour traiter le trafic reçu du dispositif de communication distant PTCT pour cette communication. En effet, quand un paquet d'une communication déjà établie est reçu par le répartiteur de charge EILB, au cours d'une nouvelle occurrence de l'étape Fl 107, cette dernière extrait l'identifiant de communication destination DCID, en extrait le masque, et consulte ensuite sa table PT_INST pour identifier l'instance de service qui correspond à ce masque.
On suppose maintenant que, lors de cette même communication, la première instance de service PTisi génère de nouveaux identifiants de communication (16381 et 11223) correspondant au masque généré à partir des consignes DG_MASKEI reçues du répartiteur de charge EILB, et propose au dispositif de communication distant PTCT ces nouveaux identifiants de communication (16381 et 11223) dans un message chiffré (étape E1108). Il convient de noter que le(s) message(s) transmettant les nouveaux identifiants de communication étant chiffré(s), son contenu n'est pas accessible par le répartiteur de charge EILB. Le dispositif de communication distant PTCT utilise dès lors l'identifiant de communication 16381 (respectivement, 11223) comme DCID inséré dans les paquets de cette communication établie avec la première instance de service PTisi.
Lors de l'interception des paquets par l'entité intermédiaire EILB, cette dernière extrait l'identifiant de communication DCID 16381 (respectivement, 11223), en extrait le masque 21, et consulte ensuite sa table d'instances de dispositifs de communication PT_INST pour trouver l'instance de service qui correspond à ce masque. De la sorte, tous les paquets interceptés sont envoyés vers la même instance de service PTisi.
Dans le mode de réalisation décrit ici, une entité intermédiaire El peut en outre vérifier (comme illustré aux étapes Fl 106 et Fl 108) si l'identifiant de communication source SCID utilisé par un dispositif de communication PT correspond au masque qui lui a été communiqué. Si ce n'est pas le cas, l'entité intermédiaire peut déclencher une procédure de négociation de masque d'identifiants de communication.
Cette variante permet de détecter une anomalie dans sa table PT_INST d'instances de dispositifs de communication. Par exemple, toujours en référence à la figure 11, on suppose que l'entité intermédiaire El détecte à l'étape Fl 110 qu'un paquet envoyé par l'instance de service PTIS1 comporte un identifiant de communication (SCID=16000, en binaire 11111010000000) qui ne correspond pas au masque (21, en binaire 10101). En conséquence, l'entité intermédiaire EILB déclenche une procédure de négociation de masque FE1111. A l'issue de cette procédure, l'instance de service PTIS1 enregistre un nouveau masque (1664, en binaire 11010000000)) auprès de l'entité intermédiaire EILB. L'entité intermédiaire EILB met à jour sa table de dispositifs de communication PT_INST avec le nouveau masque 1664. Les paquets reçus par l'entité intermédiaire avec un identifiant de communication destination DCID égal à 16000 sont envoyés à l'instance de service PTIS1.
La figure 13 représente sous forme d'organigramme un processus pouvant être mis en œuvre pour l'activation d'une entité intermédiaire EI2 dans un mode particulier de réalisation de l'invention.
On suppose dans cet exemple que cette nouvelle entité intermédiaire EI2 envoie, au cours d'une étape F1300 un message d'annonce ANNOUNCE du même type que celui envoyé à l'étape F0410 déjà décrite. Ce message d'annonce ANNOUNCE peut comporter des consignes de génération de masques DG_MASKEI2 et un ou plusieurs identifiants servjd des services de dispositifs de communication qui peuvent être traités par la fonction supportée par l'entité intermédiaire (répartition de charge de trafic, pare-feu).
On suppose dans cet exemple que le message d'annonce ANNOUNCE est reçu au cours d'une étape E1300 par un dispositif de communication PT qui fournit plusieurs services par exemple servi, serv2, serv3, ....
Sur réception de ce message d'annonce, le dispositif de communication PT vérifie (étape E1310) si le message d'ANNONCE comporte un identifiant de service servjd et, le cas échéant, si la table d'instances EI_INST d'entités intermédiaires maintenue par ce dispositif de communication, du type de celle décrite dans la figure 6, comporte déjà une entrée pour le service identifié par servjd, associé à une ou des consignes de génération de masques DG_MASKEII différentes de celles DG_MASKEI2 reçues dans ce message d'annonce.
Si c'est le cas, dans le mode de réalisation décrit ici, et afin d'éviter un conflit, le dispositif de communication PT ne crée pas de nouvelle entrée dans la table d'instances EI_INST, pour garantir que cette table ne comporte pas des consignes de génération de masques DG_MASKEII, DG_MASKEI2 différentes pour un même service servjd.
En effet, dans le mode de réalisation décrit ici, plusieurs entités intermédiaires Eli, EI2 peuvent offrir une même fonction (répartition de charge de trafic, pare-feu) à un même service servjd, à condition qu'elles fournissent des consignes de génération de masques DG_MASKEI cohérentes.
Dans le mode de réalisation décrit ici, lorsqu'une telle situation se produit, le dispositif de communication PT répond au message d'annonce en envoyant à l'entité intermédiaire EI2, au cours d'une étape E1320 un message d'enregistrement REGISTER comportant un masque d'identifiant de communication CID_MASKEH généré en application des consignes de génération de masques reçues de l'entité intermédiaire Eli.
Si le dispositif de communication PT détermine à l'étape E1310 qu'il n'y a pas de conflit, il génère un masque d'identifiant de communication CID_MASKEI2 en application des consignes véhiculées dans le message d'annonce reçu à l'étape E1300 puis l'enregistre.
En référence à la figure 14, on se place dans le contexte dans lequel deux entités intermédiaires Eli, Eb, placées sur le chemin emprunté par le trafic caractéristique des communications établies entre deux mêmes dispositifs de communication, ici un client PTCT et une instance de service PTis, modifient l'adresse IP source des paquets envoyés à cette instance de service PTis.
Dans l'exemple de la figure 14, les paquets reçus par l'instance de service PTis comportent une adresse IP source @EIi lorsqu'ils sont reçus de l'entité intermédiaire Eli et une adresse IP source @Eb lorsqu'ils sont reçus de l'entité intermédiaire EI2, ces paquets comportant le même identifiant de communication SCID ou DCID.
Lorsque l'invention est mise en œuvre dans le cas de communications établies selon le protocole QUIC, ce protocole prévoit, dans une telle situation, que le dispositif de communication PTis émette des messages PATH_CHALLENGE à l'occasion de chaque changement d'adresse IP source. Le but de ces messages PATH_CHALLENGE est de vérifier que le client PTCT est légitimement autorisé à utiliser un chemin pour envoyer ses paquets.
Dans le mode de réalisation de l'invention décrit ici, et afin d'optimiser l'acheminement du trafic dans le réseau, le dispositif de communication PTis n'envoie pas, au moins pendant une durée D déterminée, par exemple 60s, un tel message PATH_CHALLENGE mais maintient (étape E1410) deux entrées dans sa table EI_INST d'instances d'entités intermédiaires.
Dans le mode de réalisation, le dispositif de communication instance de service PTis migre la communication QUIC vers la nouvelle adresse IP s'il n'a pas reçu de paquet avec une autre adresse source pendant la durée D. Cette migration consiste à supprimer, à l'étape E1420, l'entrée correspondant à l'ancienne adresse IP dans la table EI_INST.
L'homme du métier comprendra qu'il n'est pas indispensable de supprimer l'entrée correspondant à l'ancienne adresse IP mais que ceci est avantageux pour ne pas charger inutilement la table d'instances EI_INST.
Dans le mode de réalisation décrit ici, à l'expiration de la durée D, par exemple au cours de la même étape E1420, l'instance de service PTis peut envoyer le message PATH CHALLENGE au client PTCT afin de détecter une éventuelle attaque. Mais cette opération n'est pas nécessaire à la mise en œuvre de ce mode particulier de réalisation de l'invention.
La figure 15 représente sous forme d'organigramme un processus pouvant être mis en œuvre pour retirer une entité intermédiaire EL Pour ce faire, l'entité intermédiaire El souhaitant se retirer envoie en unicast (ou diffuse), au cours d'une étape F1500, un message de retrait BYE aux dispositifs de communication PT associés à un masque d'identifiant de communication actif dans sa table d'instances de dispositifs de communication PT_INST.
Un dispositif de communication PT reçoit ce message de retrait BYE au cours d'une étape E1500. Au cours d'une étape E1510, le dispositif de communication PT met à jour la table EI_INST d'instances d'entités intermédiaires, et plus précisément l'état associé au masque d'identifiant de communication CID_MASKEI utilisé pour cette entité intermédiaire EI. Dans le mode de réalisation décrit ici, l'état est modifié pour prendre la valeur de fin d'activité OBT pour lui permettre de continuer de traiter temporairement les communications avec cette entité intermédiaire EL
La figure 16 illustre la mise à jour E1510 de la table EI_INST d'instances de service.
Dans le mode de réalisation décrit ici, le dispositif de communication PT envoie un accusé de réception ACK à l'entité intermédiaire El pour l'informer de la prise en compte du message de retrait BYE.
Dans le mode de réalisation décrit ici, lorsqu'un dispositif de communication PT reçoit un message de retrait BYE d'une entité intermédiaire, il continue d'utiliser le masque CID_MASKEI actif pour cette entité intermédiaire soit pendant une durée déterminée indiquée dans le message de retrait BYE, soit aussi longtemps qu'il existe une communication établie avec cette entité intermédiaire EI.
La figure 17 illustre un exemple de remplacement d'une entité intermédiaire Eli par une entité intermédiaire Eb pouvant être mis en œuvre dans un mode particulier de réalisation de l'invention.
Dans cet exemple, l'entité intermédiaire EI2 envoie à un dispositif de communication PT, au cours d'une étape F1700, un message d'annonce ANNOUNCE comportant une ou des consignes de génération de masques DG_MASKEII identiques à celles annoncées précédemment par l'entité intermédiaire Eli.
On suppose que le dispositif de communication PT traite ce message d'annonce comme décrit en référence à la figure 4 pour générer un masque d'identifiant en application de ces consignes puis qu'il demande l'enregistrement de ce masque auprès de l'entité intermédiaire EI2 au cours d'une étape E1702. L'entité intermédiaire EI2 accuse réception de cet enregistrement au cours d'une étape F1706.
Au cours d'une étape F7104 similaire à l'étape F1500, l'entité intermédiaire Eli envoie un message de retrait BYE au dispositif de communication PT pour l'informer qu'elle se retire. Le dispositif de communication PT accuse réception de ce retrait au cours d'une étape E1708.
La figure 18 illustre un exemple de remplacement d'une première entité intermédiaire EL par une deuxième entité intermédiaire EL, cet exemple pouvant être mis en œuvre dans un autre mode particulier de réalisation de l'invention. On suppose dans cet exemple qu'un dispositif de communication PT a reçu précédemment un message d'annonce ANNOUNCE de la première entité intermédiaire Eli comportant des premières consignes de génération de masque DG_MASKi pour une fonction fnjd et que ce dispositif de communication a généré un masque d'identifiant de communication CID_MASKEII en application de ces premières consignes.
Conformément à l'étape E0420 illustrée par la figure 4, la table d'instances d'entités intermédiaires EI_INST du dispositif de communication PT comporte un enregistrement de ce masque CID_MASKEII en association avec l'entité intermédiaire Eli.
On suppose maintenant que le dispositif de communication reçoit en provenance de l'entité intermédiaire Eb, au cours d'une étape E1802, un message d'annonce ANNOUNCE comportant des consignes de génération de masques DG_MASK2 différentes des consignes DG_MASKi, pour la même fonction fnjd.
On suppose que le dispositif de communication PT détermine au cours d'une étape F1803 que les entités intermédiaires Eli et EI2 offrent la même fonction.
Dans le mode de réalisation décrit ici, le dispositif de communication répond au message d'annonce ANNONCE reçu de la deuxième entité EI2, au cours d'une étape E1804, par un message d'enregistrement REGISTER comportant les mêmes informations que celles envoyées précédemment à la première entité Eli et en particulier le masque d'identifiant de communication CD_MASKEII généré en application des consignes DG_MASKi de la première entité intermédiaire Eli et non pas en application des consignes DG_MASK2 de la deuxième entité intermédiaire EI2.
L'entité intermédiaire EI2 accuse réception de cet enregistrement au cours d'une étape F1807.
Au cours d'une étape F1806 similaire à l'étape F1704, l'entité intermédiaire Eli envoie un message de retrait BYE au dispositif de communication PT pour l'informer qu'elle se retire. Le dispositif de communication PT accuse réception de ce retrait au cours d'une étape E1809.
Les exemples des figures 17 et 18 illustrent des situations dans lesquelles une entité intermédiaire Eli doit être retirée alors qu'une entité intermédiaire EI2 doit être activée. Le dispositif de communication reçoit un message de retrait BYE en provenance de l'entité intermédiaire Eli et un message d'annonce ANNOUNCE en provenance de l'entité intermédiaire EI2.
Dans ces deux modes de réalisation, le dispositif de communication PT peut mettre à jour sa table EI_INST d'instances d'entités intermédiaires pour indiquer que l'entité intermédiaire Eli sera bientôt indisponible. Le dispositif de communication peut alors procéder à la migration de communications vers l'entité intermédiaire EI2 ou au maintien des deux contextes pendant une période de transition. Par exemple, une communication ayant été établie avec un identifiant de communication SCID ou DCID peut être acheminée via l'entité intermédiaire EI2 sans modification d'identifiant de communication et sans interruption de communication. Les deux messages d'annonce LB_ANNOUNCE et de retrait BYE peuvent être reçus dans n'importe quel ordre chronologique.
La figure 19 représente sous forme d'organigramme un processus pouvant être mis en œuvre pour retirer un dispositif de communication PT. Pour ce faire, le dispositif de communication PT diffuse (ou envoie selon un mode unicast), au cours d'une étape E1900 un message de retrait BYE aux entités intermédiaires concernées El, c'est-à-dire associées à un masque d'identifiant de communication actif tel que consigné dans la table d'instances d'entités intermédiaires EI_INST maintenue par le dispositif de communication.
Une entité intermédiaire El reçoit ce message de retrait BYE au cours d'une étape F1900. Au cours d'une étape F1910, l'entité intermédiaire El met à jour la table PT_INST d'instances de dispositifs de communication, et plus précisément l'état associé au masque d'identifiant de communication CID_MASKEI actif pour le dispositif de communication PT. Dans le mode de réalisation décrit ici, l'état est modifié pour prendre la valeur de fin d'activité OBT indiquant que le masque est toujours actif mais destiné à devenir inactif par exemple après une échéance déterminée ou après la terminaison de la dernière communication active établie entre cette entité intermédiaire et le dispositif de communication.
La figure 20 représente un processus de renouvellement d'un masque d'identifiant de communication à l'initiative d'un dispositif de communication PT.
Dans un mode particulier de réalisation de l'invention, un dispositif de communication PT peut modifier un masque d'identifiant de communication CID_MASKEI en envoyant à une entité intermédiaire El associée à un masque d'identifiant de communication actif tel que consigné dans la table d'instances EI_INST maintenue par le dispositif de communication, au cours d'une étape E2000, un message UPDATE de modification de masque pour enregistrer auprès de cette entité un nouveau masque CID_MASKEI' généré en application des même consignes que CID_MASKEI utilisées par le dispositif de communication pour cette entité. L'entité intermédiaire El reçoit ce message au cours d'une étape F2000.
Le message UPDATE de modification de masque comporte le nouveau masque CID_MASKEI' et éventuellement une échéance pour l'activation de ce nouveau masque. Dans le mode de réalisation de l'invention décrit ici, cette échéance est optionnelle et en l'absence d'échéance, l'entité intermédiaire considère que la demande de modification doit être traitée immédiatement.
Cependant, dans le mode de réalisation décrit ici, même si l'échéance est immédiate, l'entité intermédiaire El ne remplace pas immédiatement l'ancien masque CID_MASKEI par le nouveau masque CID_MASK'EI dans sa table d'instances de dispositifs de communication PT_INST.
La figure 21 illustre la table d'instances de dispositifs de communication PT_INST gérée par l'entité intermédiaire El après réception du message UPDATE : le nouveau masque est associé à un état « ON » et l'ancien à un état de fin d'activité « OBT ». L'entité intermédiaire El envoie un message d'acquittement au dispositif de communication au cours d'une étape F2010 pour lui indiquer la bonne réception du message de modification de masque. Lorsque le dispositif de communication reçoit cet accusé de réception (étape E2010), il peut commencer à utiliser le nouveau masque CDI_MASK'EI.
Ces paquets sont traités par l'entité intermédiaire, l'état de ce nouveau masque étant actif dans la table PTJNST.
La figure 22 représente sous forme d'organigramme un processus de renouvellement d'un masque d'identifiant de communication à l'initiative d'une entité intermédiaire.
Dans un mode particulier de réalisation de l'invention, une entité intermédiaire El peut demander aux dispositifs de communication de modifier leur masque d'identifiant de communication CID_MASKEI en leur envoyant un message de renouvellement RESET, au cours d'une étape E2200.
Si ce message ne comporte pas d'argument, le dispositif de communication PT enregistre (étape F2210) un nouveau masque CID_MASK'EI auprès de cette entité El, celui-ci étant généré en application des dernières consignes fournies par cette entité.
Si ce message comporte de nouvelles consignes DG_MASK'EI, le dispositif de communication PT enregistre ces nouvelles consignes, génère un nouveau masque CID_MASK'EI en application de ces nouvelles consignes et enregistre ce nouveau masque auprès de l'entité EL
Le message de renouvellement de masque RESET peut comporter une échéance pour son activation. Dans le mode de réalisation de l'invention décrit ici, cette échéance est optionnelle et en l'absence d'échéance, l'entité intermédiaire considère que la demande de renouvellement doit être traitée immédiatement.
Si le message de renouvellement RESET comporte de nouvelles consignes DG_MASK'EI, il est préférable de choisir une échéance suffisamment longue pour éviter des conflits d'identifiants de communication.
Comme pour un renouvellement de masque à l'initiative du dispositif de communication décrit précédemment en référence aux figures 20 et 21, l'entité intermédiaire El ne remplace pas immédiatement l'ancien masque CID_MASKEI par le nouveau masque CID_MASK'EI dans sa table d'instances de dispositifs de communication PT_INST : le nouveau masque est associé à un état « ON » et l'ancien à un état de fin d'activité « OBT ».
La figure 23 représente sous forme d'organigramme un processus pouvant être mis en œuvre pour introduire un nouveau dispositif de communication PT, par exemple une nouvelle instance de service PTis pour remplacer une autre instance de service ou augmenter la capacité de traitement d'un service. Dans le mode de réalisation décrit ici, lorsqu'un nouveau dispositif de communication PT est introduit, il envoie, au cours d'une étape E2300, un message de découverte QUERY identique à celui envoyé à l'étape E0400 déjà décrite.
Une entité intermédiaire El y répond par un message d'annonce ANNOUNCE identique à celui décrit en référence à l'étape F0410 (étape F2310) et le dispositif de communication PT procède à l'enregistrement de son masque d'identifiant de communication (étape E2320).
Dans le mode de réalisation décrit ici, lorsque le nouveau dispositif de communication PT héberge une nouvelle instance de service PTis, l'entité intermédiaire El vérifie au cours d'une étape F2330 si les consignes de génération de masques d'identifiants de communication qu'elle fournit aux instances de service qui se déclarent auprès d'elle pour générer des masques d'identifiants de communication (voir étapes F0410 ou F1300) comportent suffisamment de bits pour permettre aux instances de service actives auprès d'elle et à la nouvelle instance de service de générer des masques et lui permettre ainsi de traiter les paquets émis par ou à destination de ces différentes instances de service.
Au cours de cette étape, l'entité intermédiaire El détermine :
- le nombre d'instances actives en recherchant celles associées à un masque d'identifiant de communication à l'état « ON » dans sa table d'instances de dispositifs de communication PT_INST ; et
- le nombre n de bits significatifs de ses consignes DG_MASKEI de génération de masques.
Ces informations sont suffisantes pour permettre à l'entité intermédiaire El de déterminer si les consignes ont suffisamment de bits significatifs pour répondre aux besoins d'une nouvelle instance de service, sachant que le nombre maximum théorique d'instances de service pouvant être servies est de 2n.
Si ce n'est pas le cas, l'entité intermédiaire El envoie, au cours d'une étape F2340, un message de renouvellement RESET avec de nouvelles consignes DG_MASK'EI comportant suffisamment de bits significatifs pour demander aux dispositifs de communication PTis concernés de générer un nouveau masque CID_MASKEI et de l'enregistrer auprès de cette entité EL
Par exemple, si nb est le nombre d'instances de services devant être servies par l'entité intermédiaire, le nombre de bits significatifs des nouvelles consignes DG_MASK'EI peut être choisi égal à :
(nb+l)/2 mod(2).
En référence à la figure 11 il a été expliqué comment l'invention pouvait, dans un mode particulier de réalisation, être mise en œuvre par une fonction de répartition de charge de trafic. La figure 24 illustre un mode particulier de mise en œuvre de l'invention dans lequel l'entité intermédiaire est un pare-feu EIFW, pour améliorer le niveau de sécurité offert à des dispositifs de communication, par exemple des terminaux RTuti, PTUT2 et PTUT3 protégés par ce pare-feu.
Ce mode de réalisation de l'invention peut notamment être utilisé pour se prémunir contre des attaques connues sous l'expression anglaise « connection injection », dans lesquelles, même en présence d'un pare-feu, un attaquant SA envoie avec succès du trafic émis avec une adresse IP usurpée d'un dispositif de communication légitime, par exemple une instance de PTis.
Dans le mode de réalisation décrit ici, l'entité intermédiaire El™ de type pare-feu peut maintenir dans sa table PT_INST d'instances de dispositifs de communication :
- des masques d'identifiants de communication CID_MASKINEI pour contrôler les communications entrantes vers un terminal PTUT ;
- et/ou des masques d'identifiants de communication CID_MASK0UTEI pour contrôler les communications sortantes depuis un terminal PUUT.
La table PT_INST peut en particulier contenir deux masques CID_MASKINEI et CID_MASK0UTEI pour contrôler les communications entrantes et les communications sortantes d'un même terminal.
Dans le mode de réalisation décrit ici, et comme représenté à la figure 25, la table PT_INST de dispositifs de communication comporte un attribut IN/OUT permettant de déterminer si un masque d'identifiant de communication associé à un terminal doit être utilisé pour contrôler les communications entrantes ou sortantes de ce terminal. Dans l'exemple de la figure 26, un même masque est utilisé pour filtrer les communications entrantes et sortantes d'un dispositif de communication mais l'invention ne l'impose pas.
Dans l'exemple de la figure 24, le pare-feu El™ obtient (étape F2400) l'identifiant de communication SCID, DCID véhiculé dans les paquets échangés entre les terminaux RTuti, PTUT2 et PTUT3 d'une part et l'instance de service PTis d'autre part pour contrôler les communications entrantes et sortantes des terminaux PTUTI et PTUT2. Le pare-feu est en mesure de bloquer :
- un paquet PI envoyé au terminal PTUTI par un serveur SA qui aurait usurpé l'adresse IP affectée à l'instance de service PTis si l'identifiant de communication destination DCID ne correspond pas au masque CID_MASKEII négocié entre ce terminal et le pare-feu El™ ; et
- un paquet P2 envoyé par un terminal PTUT3 usurpant l'adresse IP affectée au terminal PTUTI si l'identifiant de communication source SCID ne correspond pas au masque négocié entre le terminal PTUTI et le pare-feu El™.
Plusieurs messages ont été proposés dans les différents modes de réalisation de l'invention présentés ci-avant, uniquement à titre illustratif. Un ou plusieurs de ces messages pourraient être introduits dans le protocole QUIC pour la mise en œuvre de l'invention. Il s'agit en particulier :
- du message de découverte QUERY envoyé par les dispositifs de communication pour découvrir des entités intermédiaires ;
- du message d'annonce ANNOUNCE envoyé par les entités intermédiaires pour annoncer leur présence ;
- du message d'enregistrement REGISTER utilisé par un dispositif de communication pour enregistrer un masque d'identifiant de communication auprès d'une ou plusieurs entités intermédiaires ;
- du message CONFLICT utilisé par les entités intermédiaires pour signaler un conflit - du message BYE envoyé par une entité intermédiaire ou par un dispositif de communication pour se retirer ;
- du message UPDATE envoyé par un dispositif de communication PT pour modifier un masque d'identifiant de communication ;
- du message RESET envoyé par une entité intermédiaire pour demander aux dispositifs de communication de modifier leur masque d'identifiant de communication.
La figure 26 représente l'architecture matérielle d'une entité intermédiaire El conforme à un mode particulier de réalisation de l'invention. Dans ce mode de réalisation particulier, cette entité intermédiaire a l'architecture matérielle d'un ordinateur. Elle comporte un processeur 261, une mémoire morte de type ROM 262, une mémoire vive 263 et une mémoire non volatile réinscriptible 264, et des moyens de communication 265.
La mémoire morte 262 comporte un programme d'ordinateur 266 comportant des instructions qui lorsqu'elles sont exécutées par le processeur 261 mettent en œuvre un procédé de gestion de communication conforme à l'invention et notamment les étapes FXX décrites précédemment.
La mémoire non volatile réinscriptible 264 comporte notamment :
- les identifiants servjd des services qui peuvent être traités par la fonction de l'entité intermédiaire El ;
- une ou des consignes DG_MASKEI de génération de masques ;
- une table PT_INST d'instances de dispositifs de communication du type de celle représentée dans la figure 8;
Les paquets P et les différents messages rappelés ci-dessus sont mémorisés dans la mémoire vive 263 le temps de leur traitement par le processeur 261.
La figure 27 représente l'architecture matérielle d'un dispositif de communication PT conforme à un mode particulier de réalisation de l'invention. Dans ce mode de réalisation particulier, ce dispositif de communication a l'architecture matérielle d'un ordinateur. Il comporte un processeur 271, une mémoire morte de type ROM 272, une mémoire vive 273, une mémoire non volatile réinscriptible 274, et des moyens de communication 275.
La mémoire morte 272 comporte un programme d'ordinateur 276 comportant des instructions qui lorsqu'elles sont exécutées par le processeur 271 mettent en œuvre un procédé de communication conforme à l'invention et notamment les étapes EXX décrites précédemment.
La mémoire non volatile réinscriptible 274 comporte :
- une table EI_INST d'instances d'entités intermédiaires du type de celle représentée dans la figure
6.
Les paquets P et les différents messages rappelés ci-dessus sont mémorisés dans la mémoire vive 273 le temps de leur traitement par le processeur 271. Dans le mode de réalisation décrit ici, les moyens de communication 265 et 275 sont configurés pour communiquer selon le protocole QUIC. Les moyens de communication 265 de l'entité intermédiaire sont configurés pour intercepter les paquets P conformes au protocole QUIC échangés par les moyens de communication 275 de dispositifs de communication PT. Ces moyens de communication sont également configurés pour pouvoir envoyer ou recevoir les messages rappelés ci-dessus.
La figure 28 représente un système SYS conforme à un mode particulier de réalisation de l'invention. Ce système comporte deux dispositifs de communication RTi, PT2 et une entité intermédiaire El conformes à un mode particulier de réalisation de l'invention, l'entité intermédiaire étant placée sur un chemin utilisé pour établir des communications entre ces dispositifs de communication.
Sur cette figure 28, on a représenté l'architecture fonctionnelle de l'entité intermédiaire El et l'architecture fonctionnelle des dispositifs de communication PTi et PT2.
L'entité intermédiaire El comporte :
- un module MO d'obtention configuré pour obtenir un identifiant de communication SCID, DCID véhiculé dans un paquet échangé au cours de ladite communication;
- un module de traitement MT configuré pour traiter ce paquet en fonction d'un résultat d'une vérification d'une conformité dudit identifiant de communication SCID, DCID selon au moins un masque CID_MASKEI d'identifiant de communication accessible par l'entité intermédiaire EL
Ces modules peuvent être implémentés par les moyens matériels et logiciels d'une entité intermédiaire représentés dans la figure 26.
Le dispositif de communication PTi comporte :
- un module MG de génération d'identifiants de communication configuré pour générer au moins un identifiant de communication destiné à être utilisé comme identifiant de communication SCID, DCID dans une communication établie entre le dispositif de communication PTi et le dispositif de communication PT2 dans un réseau de communication, cet identifiant étant conforme selon au moins un masque CID_MASKEI d'identifant de communication accessible à l'entité intermédiaire El; et
- un module ME d'envoi de paquets configuré pour envoyer au moins un paquet de données comportant cet identifiant de communication SCID, DCID dans le cadre de cette communication.
Ces modules peuvent être impémentés par les moyens matériels et logiciels d'un dispositif de communication représentés à la figure 26.

Claims

REVENDICATIONS
[Revendication 1] Procédé de gestion d'une communication entre au moins un premier dispositif de communication (PTi) et au moins un deuxième dispositif de communication (PT2) dans un réseau de communication, ledit procédé étant mis en œuvre par une entité dite intermédiaire (El) placée sur au moins un chemin emprunté par des paquets de données de ladite communication, ledit procédé comportant :
- une étape (Fl 107, Fl 106, F2400) d'obtention d'un identifiant de communication (SCID, DCID) véhiculé dans un paquet de données échangé au cours de ladite communication; et
- une étape de traitement dudit paquet de données en fonction d'un résultat d'une vérification d'une conformité dudit identifiant de communication (SCID, DCID) avec au moins un masque (CID_MASKEI) d'identifiant de communication accessible par ladite entité intermédiaire (El).
[Revendication 2] Procédé de gestion selon la revendication 1, dans lequel ledit masque d'identifiant de communication (CID_MASKEI) est reçu (F0440) en provenance d'un dit dispositif de communication (PT1, PT2) et associé par ladite entité intermédiaire avec ledit dispositif de communication ;
- ladite étape de traitement étant en outre déterminée en fonction du dispositif de communication associé audit masque (CID_MASKEI).
[Revendication 3] Procédé de gestion selon la revendication 2, caractérisé en ce qu'il comporte :
- une étape (F0410) d'envoi d'un message d'annonce (ANNOUNCE) comportant au moins une consigne (DG_MASK) de génération de masques d'identifiants de communication ;
- ledit masque (CID_MASKEI) d'identifiant de communication (CID_MASKEI) étant reçu (F0440) en provenance dudit dispositif de communication (PT1, PT2) en réponse audit message d'annonce.
[Revendication 4] Procédé de gestion selon la revendication 3, dans lequel ladite entité intermédiaire (EI2) offre une fonction déterminée (fnjd), caractérisé en ce qu'il comporte une étape (F1804) de réception en provenance d'au moins un dit dispositif de communication d'au moins un masque d'identifiant de communication généré par ce dispositif de communication à partir d'au moins une consigne de génération de masques d'identifiants de communication fournie par une autre entité intermédiaire offrant ladite fonction déterminée.
[Revendication 5] Procédé de gestion d'une communication selon la revendication 3 ou 4, dans lequel ledit message d'annonce (ANNOUNCE) comporte un identifiant (servjd) d'un service qui identifie un service dont des paquets de données peuvent être traités par ladite entité intermédiaire (El).
[Revendication 6] Procédé de gestion d'une communication selon l'une quelconque des revendications 2 à 5 comportant une étape (F0450) de détection de conflit, un conflit étant détecté si ledit masque d'identifiant de communication reçu (F0440) en provenance d'un dispositif de communication constituant une instance d'un service a déjà été associé par ladite entité intermédiaire avec au moins un autre dispositif de communication constituant une instance différente du même service ; et
- une étape de déclenchement d'une modification dudit masque d'identifiant de communication par au moins un de ces dispositifs de communication.
[Revendication 7] Procédé de gestion d'une communication selon l'une quelconque des revendications 2 à 6 dans lequel ladite entité intermédiaire met en œuvre une fonction de répartition de charge de trafic, ladite étape de traitement dudit paquet comportant l'acheminement dudit paquet vers un dit dispositif de communication associé à un masque d'identifiant de communication (CID_MASKEI) auquel est conforme ledit identifiant de communication (SCID,DCID), et d'un algorithme de répartition de charge de trafic.
[Revendication 8] Procédé de gestion d'une communication selon l'une quelconque des revendications 1 à 6 dans lequel ladite entité intermédiaire met en œuvre une fonction pare-feu, ladite étape de traitement dudit paquet de données comportant le filtrage dudit paquet en fonction de la conformité ou non dudit identifiant de communication (SCID, DCID) avec ledit au moins un masque d'identifiant de communication.
[Revendication 9] Procédé de gestion d'une communication selon l'une quelconque des revendications 3 à 8 comportant :
- une étape de vérification (F2330) pour vérifier si ladite entité intermédiaire (El) peut servir ledit dispositif de communication (RTi, PT2) en fonction :
(i) d'un nombre de dispositifs de communication déjà enregistrés par ladite entité intermédiaire (El) en association avec un masque d'identifiant de communication (CID_MASKEI) généré en application de ladite au moins une consigne (DG_MASKEI) de génération de masques ; et
(ii) d'un nombre de bits définis par ladite au moins une consigne (DG_MASKEI) ; et
- si ce n'est pas le cas, une étape (F2340) d'envoi d'un message de renouvellement (RESET) avec au moins une nouvelle consigne (DG_MASK'EI) définissant un nombre supérieur de bits, ledit message de renouvellement demandant audit dispositif de communication (PT1) et auxdits dispositifs de communication déjà enregistrés de générer un nouveau masque (CID_MASKEI) en application de ladite au moins une nouvelle consigne (DG_MASK'EI).
[Revendication 10] Procédé de communication mis en œuvre par un premier dispositif de communication (PT1) dans un réseau de communication, ledit procédé comportant :
- une étape (El 106, El 108) de génération d'au moins un identifiant destiné à être utilisé comme identifiant de communication (SCID, DCID) dans une communication entre ledit premier dispositif de communication (PT1) et au moins un deuxième dispositif de communication (PT2), ledit identifiant étant conforme à au moins un masque (CID_MASKEI) d'identifiant de communication accessible par au moins une entité dite intermédiaire (El) placée sur au moins un chemin emprunté par des paquets de données de ladite communication ; et - une étape (El 106, El 108) d'envoi d'au moins un paquet de données comportant ledit identifiant (SCID, DCID) dans le cadre de ladite communication.
[Revendication 11] Procédé de communication selon la revendication 10, caractérisé en ce que ledit dispositif de communication (PT1) utilise (E1106) ledit identifiant de communication (SCI) en tant qu'identifiant de communication source (SCID) dans ledit paquet de données.
[Revendication 12] Procédé de communication selon la revendication 10, caractérisé en ce que ledit dispositif de communication (PT1) envoie (E1108) ledit identifiant de communication (SCI) chiffré dans ledit paquet de données au dit deuxième dispositif de communication pour que celui-ci utilise ledit identifiant en tant qu'identifiant de communication destination (DCID) dans un paquet de données ultérieur de la communication.
[Revendication 13] Procédé de communication selon l'une quelconque des revendications 10 à 12, ledit procédé comportant :
- une étape (E0430, E1804) de génération d'au moins un masque (CID_MASKEI) d'identifiant de communication en appliquant au moins une consigne (DG_MASKEI) de génération de masques d'identifiants de communication ; et
- une étape (E0430, E1804) d'enregistrement dudit masque (CID_MASKEI) auprès de ladite entité (El) intermédiaire.
[Revendication 14] Procédé de communication selon la revendication 13, caractérisé en ce que ledit dispositif de communication :
- détermine (E1803) que ladite entité intermédiaire (El) offre la même fonction qu'une autre entité intermédiaire ; et en ce qu'il
- enregistre (E1804) auprès de ladite entité intermédiaire (El) un masque (CID_MASKEI) d'identifiant de communication en application de ladite au moins une consigne (DG_MASKEI) de génération de masques utilisée pour cette autre entité intermédiaire.
[Revendication 15] Procédé de communication selon la revendications 13 ou 14 dans lequel dispositif de communication :
- ledit premier dispositif de communication (PT1) vérifie (E1310), avant d'enregistrer pour un service (servjd) déterminé, un masque (CID_MASKEI) généré en application de ladite au moins une consigne (DG_MASKEI), auprès de ladite entité intermédiaire, qu'il n'a pas déjà enregistré auprès d'une autre entité intermédiaire un masque pour le même service et généré en application d'au moins une deuxième consigne différente de ladite au moins une consigne (DG_MASKEI) ; et
- si ledit premier dispositif de communication (PT1) détermine qu'il a déjà enregistré un masque pour le même service auprès d'une autre entité intermédiaire, il enregistre auprès de ladite entité intermédiaire un masque généré en application de ladite au moins une deuxième consigne.
[Revendication 16] Procédé selon l'une quelconque des revendications 3 à 9 et 13 à 15 dans lequel ladite au moins une consigne (DG_MASKEI) de génération de masques d'identifiants de communication comporte au moins une information parmi :
- une information représentative d'une position d'un premier bit d'un identifiant de communication (SCID, DCID) correspondant à un masque (CID_MASKEI) de cet identifiant ;
- une information représentative d'une position d'un dernier bit dudit identifiant de communication (SCID, DCID) correspondant audit masque (CID_MASKEI) ; et
- une information représentative des positions ou d'un nombre de bits dudit identifiant de communication (SCID, DCID) correspondant audit masque (CID_MASKEI).
[Revendication 17] Entité dite intermédiaire (El) configurée pour être placée sur au moins un chemin emprunté par des paquets de données d'une communication entre au moins un premier dispositif de communication (PTi) et au moins un deuxième dispositif de communication (PT2) dans un réseau de communication, ladite entité comportant :
- un module (MO) d'obtention configuré pour obtenir un identifiant de communication (SCID, DCID) véhiculé dans un paquet échangé au cours de ladite communication ; et
- un module de traitement (MT) configuré pour traiter ledit paquet de données en fonction d'un résultat d'une vérification d'une conformité dudit identifiant de communication (SCID, DCID) avec au moins un masque (CID_MASKEI) d'identifiant de communication accessible par ladite entité intermédiaire (El).
[Revendication 18] Dispositif de communication (PT1) comportant :
- un module (MG) de génération d'identifiants de communication configuré pour générer au moins un identifiant destiné à être utilisé comme identifiant de communication (SCID, DCID) dans une communication entre ledit dispositif de communication (PT1) et au moins un deuxième dispositif de communication (PT2) dans un réseau de communication, ledit identifiant étant conforme à au moins un masque (CID_MASKEI) d'identifiant de communication accessible par au moins une entité intermédiaire placée sur au moins un chemin emprunté par des paquets de données de ladite communication ; et
- un module (E1106, E1108) d'envoi configuré pour envoyer au moins un paquet de données comportant ledit identifiant (SCID, DCID) dans le cadre de ladite communication.
[Revendication 19] Système de communication comportant au moins :
- un dispositif de communication (PT1) selon la revendication 18, ledit dispositif de communication étant configuré pour communiquer avec au moins un deuxième dispositif de communication (PT2) ; et
- une entité intermédiaire (El) selon la revendication 17 configurée pour être placée sur au moins un chemin emprunté par des paquets de données d'une communication entre lesdits dispositifs de communication (PT1, PT2).
[Revendication 20] Procédé selon l'une quelconque des revendications 1 à 16 dans lequel ladite communication entre ledit au moins un premier dispositif de communication et ledit au moins un deuxième dispositif de communication est établie selon le protocole QUIC.
PCT/FR2021/050624 2020-04-10 2021-04-08 Procede mis en œuvre par une entite intermediaire pour gerer une communication entre deux dispositifs de communication WO2021205124A1 (fr)

Priority Applications (3)

Application Number Priority Date Filing Date Title
EP21724726.1A EP4133707A1 (fr) 2020-04-10 2021-04-08 Procede mis en oeuvre par une entite intermediaire pour gerer une communication entre deux dispositifs de communication
CN202180039694.8A CN115699681A (zh) 2020-04-10 2021-04-08 由中间实体实现的用于管理两个通信设备之间的通信的方法
US17/917,464 US20230179578A1 (en) 2020-04-10 2021-04-08 Method implemented by an intermediate entity for managing communication between two communication devices

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FRFR2003621 2020-04-10
FR2003621A FR3109255A1 (fr) 2020-04-10 2020-04-10 Procédé mis en œuvre par une entité intermédiaire pour gérer une communication entre deux dispositifs de communication

Publications (1)

Publication Number Publication Date
WO2021205124A1 true WO2021205124A1 (fr) 2021-10-14

Family

ID=71784202

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/FR2021/050624 WO2021205124A1 (fr) 2020-04-10 2021-04-08 Procede mis en œuvre par une entite intermediaire pour gerer une communication entre deux dispositifs de communication

Country Status (5)

Country Link
US (1) US20230179578A1 (fr)
EP (1) EP4133707A1 (fr)
CN (1) CN115699681A (fr)
FR (1) FR3109255A1 (fr)
WO (1) WO2021205124A1 (fr)

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN110177082A (zh) * 2019-04-25 2019-08-27 阿里巴巴集团控股有限公司 一种数据处理方法、设备、介质以及装置

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN110177082A (zh) * 2019-04-25 2019-08-27 阿里巴巴集团控股有限公司 一种数据处理方法、设备、介质以及装置

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
DUKE F5 NETWORKS M ET AL: "QUIC-LB: Generating Routable QUIC Connection IDs; draft-ietf-quic-load-balancers-02.txt", no. 2, 9 March 2020 (2020-03-09), pages 1 - 27, XP015138423, Retrieved from the Internet <URL:https://tools.ietf.org/html/draft-ietf-quic-load-balancers-02> [retrieved on 20200309] *
IYENGAR, J.M. THOMSON, QUIC: A UDP-BASED MULTIPLEXED AND SECURE TRANSPORT, 2019

Also Published As

Publication number Publication date
EP4133707A1 (fr) 2023-02-15
CN115699681A (zh) 2023-02-03
US20230179578A1 (en) 2023-06-08
FR3109255A1 (fr) 2021-10-15

Similar Documents

Publication Publication Date Title
EP3476095B1 (fr) Procédé de communication udp via des chemins multiples entre deux terminaux
FR3067550A1 (fr) Procede de communication quic via des chemins multiples
FR2872983A1 (fr) Systeme de pare-feu protegeant une communaute d&#39;appareils, appareil participant au systeme et methode de mise a jour des regles de pare-feu au sein du systeme
WO2020260813A1 (fr) Procédé de gestion d&#39;une communication entre terminaux dans un réseau de communication, et dispositifs pour la mise en oeuvre du procédé
EP3695571B1 (fr) Dispositif et procédé de transmission de données
EP3568989A1 (fr) Procédés et dispositifs de vérification de la validité d&#39;une délégation de diffusion de contenus chiffrés
FR3074626A1 (fr) Procede d&#39;acheminement de donnees d&#39;une session initialisee entre un terminal et un serveur
EP3891935A1 (fr) Procédé de configuration d&#39;un noeud d&#39;un réseau
WO2021205124A1 (fr) Procede mis en œuvre par une entite intermediaire pour gerer une communication entre deux dispositifs de communication
EP3949287B1 (fr) Passerelle et procédé de différentiation de trafic émis par la passerelle, dispositif et procédé gestion du trafic
EP4222994A1 (fr) Procedes de configuration d&#39;un equipement utilisateur, de negociation avec une entite du reseau, et de gestion d&#39;une connexion, et dispositifs associes
WO2010072953A1 (fr) SYSTEME D&#39;ACHEMINEMENT D&#39;UN PAQUET DE DONNEES IPv4
EP3811587A1 (fr) Procédé de modification de messages par un équipement sur un chemin de communication établi entre deux noeuds
EP3087719A1 (fr) Procédé de ralentissement d&#39;une communication dans un réseau
EP4338375A1 (fr) Procede de defense contre une tentative de deconnexion entre deux entites, systeme associe
WO2009080971A1 (fr) Procede de configuration d&#39;un terminal d&#39;utilisateur dans un reseau de telephonie ip
EP1432213B1 (fr) Plate-forme de médiation et réseau de transport de messages
WO2024121281A1 (fr) Procédé de gestion d&#39;un ensemble d&#39;adresses ip, procédé de collaboration et dispositifs configurés pour mettre en œuvre ces procédés
WO2023242318A1 (fr) Procédé de communication entre un premier équipement et un serveur distant, procédé de gestion des communications, premier équipement, serveur distant et programme d&#39;ordinateur correspondants.
WO2024068722A1 (fr) Procedes de resolution de nom, de communication, de traitement de messages et serveur, dispositif client et noeud relais correspondants
WO2007060364A1 (fr) Procede pour selectionner dans un routeur une route parmi au moins deux routes relatives a une meme adresse reseau de destination
FR2954838A1 (fr) Securisation des flux de donnees dans un systeme informatique

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 21724726

Country of ref document: EP

Kind code of ref document: A1

ENP Entry into the national phase

Ref document number: 2021724726

Country of ref document: EP

Effective date: 20221110

NENP Non-entry into the national phase

Ref country code: DE