Communication management methods and associated devices

Abstract

The invention relates to a method for managing communications made according to a given transmission protocol, the method being implemented by a first device and comprising, after detecting a cyberattack, a step of enabling (F40), in the first device, a collaboration with at least one entity of the network to mitigate the cyberattack, the collaboration comprising, during at least one of said communications made by the first device via the network according to the given transmission protocol, performing (F70), by the first device, at least one determined action, referred to as a collaborative action.

Description

Technical Field

[0001] This invention relates to the general telecommunications field.

[0002] More specifically, the present invention relates to a mechanism for facilitating the management and operation of security services operating within an IP (Internet Protocol) network in the event of a detected network attack. Such services may be, for example, intrusion or network attack detection services, services for filtering traffic via firewalls, address translation (or NAT for network address translation) services, etc.

[0003] This invention is particularly applicable to Denial-of-Service (DoS) network attacks or Distributed DoS (DDoS) network attacks. A DoS attack can be defined as an attempt to render resources (such as network or computing resources) of a computing domain unavailable to its users. Background Technology

[0004] DDoS attacks are growing in scale and can compromise hundreds of thousands of user devices (fixed or mobile devices, connected objects, servers, network resources, routers such as CPEs, STBs, digital decoders, service instances, or service functions), which can in turn be used as relays to amplify the harmful power of these attacks. Symantec, in its 2019 annual report, documented that nearly 24,000 applications embedded in mobile devices were blocked daily by such attacks, with attacks targeting connected objects increasing by 600% between 2016 and 2017, and attack traffic increasing from 5% of global network traffic in 2016 to 7.8% in 2017.

[0005] DDoS attacks are becoming increasingly frequent and intense. Furthermore, they are wide-ranging in terms of scale (attack volume, attack magnitude, etc.) and scope of harm (targeting a single machine, or multiple machines via corporate LANs, carrier networks, etc.). The targets of these attacks, or the relays used to propagate them, also vary greatly: fixed or mobile terminals, connected objects, servers, network resources, etc.

[0006] To protect their computing resources from such attacks, many companies subscribe to DPS (for "DDoS Protection Service") protection products. When a DPS protection service has been subscribed to an access provider, the access provider typically appears on the path taken by traffic entering and / or leaving the computing domain monitored and protected by the DPS service. However, such a task for a DPS service can prove difficult when incoming and / or outgoing traffic is encrypted. Encryption is now increasingly prevalent, especially with the growing use of the QUIC transport protocol in certain commonly used applications, such as browsers provided by companies like Mozilla or Google for accessing internet websites. This increase reflects a primary concern for users who want to ensure the confidentiality of their communications and the data exchanged during said communications.

[0007] As is well known, the QUIC protocol is a protocol based on the UDP (User Datagram Protocol). The goal of the QUIC protocol is, in particular, to reduce the latency typically observed when establishing TCP (Transmission Control Protocol) connections (thus allowing for faster data exchange) and to better accommodate the presence of intermediate entities (e.g., firewalls, NAT) along the communication path. For example, the QUIC protocol is described in the IETF document entitled "QUIC: A UDP-based multiplexed and secure transport," draft-ietf-quic-transport, 2019.

[0008] According to the QUIC protocol, not only is the payload data exchanged during communication encrypted, but most communication control information (often referred to as "connection" in the context of the QUIC protocol) is also encrypted. The amount of QUIC information sent in unencrypted form is limited, such as... Figure 1 The diagram shown illustrates the structure of the short message header QUIC data group.

[0009] Such a packet includes a public (i.e., unencrypted) header 1, which comprises three elements: a first byte 1-1 containing various flags |0|1|S|R|C|K|P|P|, a second element 1-2 corresponding to a connection identifier (CID) that allows the packet to be routed, and a third element 1-3 containing a packet number. The packet also includes an encrypted portion 2, which specifically contains the payload data transmitted by the packet, as well as various connection control information, such as information about the number of supported channels, information about connection migration, and information about changes to the connection identifier.

[0010] Furthermore, since the QUIC protocol is based on the UDP transport protocol, QUIC packets do not disclose any information useful for traffic filtering at the computing domain ingress, such as connection start and end information, acknowledgments, etc.

[0011] Therefore, DPS services find it difficult to determine whether QUIC traffic destined for a user's equipment is legitimate (i.e., received with the consent of the intended recipient of the QUIC packet) or suspicious. Consequently, the QUIC protocol is particularly vulnerable to DDoS attacks, especially reflection attacks and identity theft attacks.

[0012] One approach to this problem is to deploy "agents" within the access provider's network. These agents would be responsible for intercepting characteristic data of users' QUIC communications in a manner transparent to the users, and analyzing this data to determine whether the traffic transmitted through them is legitimate (in other words, with user consent) or suspicious (i.e., potentially associated with a cyberattack). To do this, each agent should maintain a connection with every device involved in the communication, without explicitly indicating this to them.

[0013] However, this approach seems impractical.

[0014] In fact, such proxies will operate without the user's knowledge and explicit consent, even if it jeopardizes the confidentiality of their communications and may harm their personal data.

[0015] Furthermore, this approach introduces new attack vectors, as highlighted by Z. Durumeric et al. in their 2017 NDSS article, "The security impact of HTTPS interception," which states that intercepting encrypted communications makes them more vulnerable to attack.

[0016] Each agent must also maintain the state of each connection it maintains, which requires significant resources (network, CPU, etc.). Therefore, it actually constitutes a particularly sensitive and critical element in the event of a failure (also known as SPOF (“single point of failure)”).

[0017] Furthermore, the device originating from a QUIC communication can be multi-interface (that is, having multiple access interfaces that provide connectivity to them via one or more networks), thus establishing communication using multiple paths or conversely, using only one path. An agent located on one of these paths will not see the global traffic associated with such a multi-interface device.

[0018] Therefore, a mechanism is needed that can improve the security of the computing domain, thereby improving the security of its user communications (including when these communications are based on encrypted transport protocols such as QUIC), and can do so without compromising the confidentiality of these communications or compromising the user's personal data. Summary of the Invention

[0019] According to a first aspect, the present invention addresses this need by providing a method for managing communications of a first device in a network according to a given transport protocol, the method being implemented by the first device and including, after a network attack is detected, enabling cooperation on the first device with at least one entity in the network to mitigate the network attack, the cooperation including, during at least one of the communications conducted by the first device via the network according to the given transport protocol, the first device performing at least one determined action, referred to as a cooperative action.

[0020] Relatedly, the present invention also relates to a first device belonging to a network, the first device including an activation module that is triggered after a network attack is detected and configured to enable cooperation with at least one entity of the network on the first device to mitigate the network attack. The activation module is configured to perform at least one determined action, referred to as a cooperation action, during the cooperation, during at least one communication made by the first device via the network according to a given transport protocol.

[0021] There are no restrictions on the nature of the first device or network entity. The first device can be user equipment (acting as a client or server) that provides connectivity to the network, such as terminals, servers, gateways, etc., but it can also be equipment in the actual network infrastructure that helps manage communications within the network, such as routers. Similarly, a network entity can be any equipment in the network capable of participating in the management of detected network attacks, such as equipment implementing intrusion detection and / or attack mitigation functions (e.g., DPS services), firewall functions, NAT functions, or even a network controller. The first device and the network entity can be managed by the same administrative entity. This is often the case within corporate networks.

[0022] Furthermore, while the present invention is preferably applicable to the QUIC transport protocol, it can also be implemented for other transport protocols that may encounter problems similar to those described above for the QUIC protocol (e.g., inability to access communication control information, lack of explicit consent signals in packets, etc.).

[0023] Therefore, this invention proposes that, upon detection of a network attack, a device communicating via the network (the "first device" in this invention) is requested or prompted to cooperate with one or more entities on the network to mitigate the attack. Thus, all or only some of the devices involved in the communication may be requested to cooperate with the network.

[0024] This collaboration involves performing one or more specific actions, which may often depend on the transport protocol used to establish the communication and its characteristics. These actions are designed to facilitate the task of network entities responsible for mitigating cyberattacks in distinguishing legitimate traffic (that is, traffic that the user of the device consents to) from suspicious traffic that may be attributable to an attack.

[0025] For communication according to a given transport protocol, such actions (referred to as cooperative actions in the remainder of this specification) can be, for example:

[0026] • Disclose control information related to this communication;

[0027] • Freeze the migration of communication identifiers (or connection identifiers) used during communication; or

[0028] • Discontinue the use of the transport protocol under discussion during communication.

[0029] These exemplary actions are preferably applicable to the context of the QUIC protocol, where control information related to communication is encrypted and inaccessible to network entities. With such actions, entities involved in mitigating an ongoing cyberattack can better see global traffic destined for or sent by the first device and can more easily determine whether the traffic is legitimate or associated with an attack by analyzing it, and take appropriate action accordingly.

[0030] Furthermore, these actions are highly advantageous because they enable the maintenance of confidentiality in communications, since at most communication control information is disclosed or remains unchanged, thus allowing network entities to more easily associate the data streams exchanged between them with the devices at the origin or destination of those streams.

[0031] Compared to solutions that unilaterally block the use of a considered transport protocol, this invention provides a less aggressive and more effective solution through cooperative action. This advantageously allows for the preservation of user consent and interests, and in particular, significantly improves the quality of the connection service perceived by the user. For example, within the framework of the QUIC protocol, some services or applications rely entirely on the use of the protocol; permanently blocking the use of the QUIC protocol would deprive users of these services and applications and would violate the neutrality principle of the Internet.

[0032] Furthermore, with this invention, the device avoids experiencing prolonged delays during the establishment of its communication, which are related to unilateral filtering of communication by the network according to the QUIC protocol (this delay stems from the time the device observes that it has failed to establish its communication according to the QUIC protocol due to filtering performed by the network). Instead, within the framework of this invention, cooperative actions are initiated by the device itself, including (temporarily) disabling the use of the QUIC protocol.

[0033] Furthermore, it should be noted that these exemplary actions (and more generally, actions performed by devices within the collaborative framework inspired by this invention) are not necessarily intended to assist specific entities within the network. According to these examples, the first device does not necessarily send a specific message to a specific entity for the purpose of collaboration; rather, all or some network entities placed along the communication path can benefit from it.

[0034] Of course, these exemplary actions are given merely as instructions, and other actions can be conceived as variations, depending on the transport protocol under consideration. Furthermore, cooperation enabled according to the invention may also include combinations of actions, such as disclosing control information and freezing the migration of communication identifiers.

[0035] Therefore, the collaboration proposed in this invention advantageously enables an increase in the effectiveness of mitigation efforts taken within the network by more easily targeting risky communications. It also enables the avoidance of abrupt communication interruptions after a network attack is detected.

[0036] Furthermore, this invention enables the association of (“first”) communication devices with attack management. These communication devices are those that maintain control over the cooperative actions being performed (i.e., those that execute these cooperative actions during their communication), even if they may be selected or recommended by network entities involved in attack mitigation. Therefore, this invention provides transparency regarding processing operations performed by the network.

[0037] In a particular embodiment of the invention, the at least one cooperative action is performed by a first device for a defined duration.

[0038] This duration can be defined by default or fixed by the network or the first device, and can be readjusted or extended if necessary, such as while a network attack is ongoing. Therefore, this ensures the special nature of the collaboration implemented in this way, thereby protecting the user's interests. Such precautions allow the first device to control the information it shares during collaboration and prevent network abuse of this collaboration.

[0039] In one particular embodiment, the execution duration of the at least one collaborative action is selected to be greater than 60 minutes. Indeed, research indicates that the vast majority of recent attacks lasted for more than an hour, with a small percentage lasting more than 12 hours, and even exceeding a day.

[0040] It should be noted that, in one particular embodiment, the number of collaborations with the network that can be enabled by the first device may also be limited. For example, it is conceivable that only one collaboration proposed in this invention may be enabled every 24 hours to avoid certain network abuses.

[0041] In one particular embodiment, the activation step is triggered by receiving a message proposing the collaboration from at least one entity in the network.

[0042] In other words, collaboration can be initiated by a network entity involved in mitigating an ongoing attack, for example, because that entity has difficulty identifying traffic originating from or destined for the first device (whether it is consent or suspicion).

[0043] As a variant, collaboration can be decided locally, i.e., on the first device, for example, because the first device has been notified of a cyberattack or has detected a cyberattack, or because one of its communicators has requested it to do so during communication.

[0044] Therefore, the implementation of the present invention is particularly flexible.

[0045] In a particular embodiment of the invention, the method for managing communications further includes the step of sending an information message to at least one second device participating in at least one of the communications with the first device according to the given transport protocol, the information message notifying the second device that the first device performs the at least one cooperative action.

[0046] Thus, the first device informs its communicators of the fact that it desires or has agreed to cooperate with the network entity in all or some of its communications, especially those communications involving the second device so notified. Therefore, the cooperation is implemented completely transparently for each device involved in the communications affected by it.

[0047] The first device may also perform the at least one cooperative action on the condition that it receives consent from the second device.

[0048] However, it should be noted that, depending on the envisioned collaborative action and its execution conditions, notifying the communicator and obtaining their consent may be optional.

[0049] In one particular embodiment, the information message sent by the first device to the second device includes at least one execution condition for the cooperative action.

[0050] Such execution conditions include, for example, the duration of the collaborative action, or the communication or application to which the collaborative action is applied (e.g., the direction in which the collaboration is applied, i.e., from the first device to the second device and / or from the second device to the first device).

[0051] In view of the above, in order to implement cooperation between communication devices and network entities, the present invention relies not only on the communication devices themselves (the first and second devices within the meaning of the present invention), but also on the network entities that benefit from the cooperation.

[0052] Therefore, according to a second aspect, the present invention also relates to a method for communicating with a first device on a network, the method being implemented by a second device and comprising:

[0053] • The step of receiving an information message from the first device, the information message notifying the second device that the first device performs at least one determined action during at least one communication with the second device in accordance with a given transmission protocol, the action being referred to as a cooperative action and allowing cooperation with at least one entity in the network to mitigate network attacks;

[0054] • If the second device accepts to perform the collaborative action, it notifies the first device of its consent.

[0055] Relatedly, the present invention also relates to a device, referred to as a second device, which includes a communication module for communicating with a first device on a network, the communication module being configured to:

[0056] • Receive an information message from the first device that notifies the second device that the first device will perform at least one determined action during at least one communication with the second device in accordance with a given transmission protocol. The action is referred to as a cooperative action and allows cooperation with at least one entity of the network to mitigate network attacks.

[0057] If the second device accepts to perform the collaborative action, it notifies the first device of its consent.

[0058] The communication method and the second device benefit from the same advantages described above as those of the management method and the first device according to the invention.

[0059] In a specific embodiment of the communication method and the management method, at least one data packet exchanged during the communication between the first device and the second device according to a given transport protocol includes at least one header indicating at least one piece of control information for the communication in an unencrypted form, the at least one piece of control information being derived from:

[0060] • The establishment status of this communication;

[0061] The first or second device agrees to send and / or receive data packets during the communication; and

[0062] • The first or second device agrees or disagrees with the communication.

[0063] This different control information provides payload data to network entities, which can be used (because it is provided in unencrypted form) to improve security and more effectively mitigate ongoing cyberattacks.

[0064] The presence of this control information in the header of packets exchanged between the first and second devices advantageously allows for the exchange of signaling over the network without increasing the amount of signaling exchanged. In the context of the QUIC protocol, this information can be encoded, for example, in a reserved field of the short or long header of a QUIC packet. However, as a variation, the control information can be sent in a dedicated message specifically provided for this purpose.

[0065] It should be noted that, traditionally, when a device disagrees with a communication, it is typically configured to ignore that communication. Sending control information to network entities reflecting a device's disagreement with the communication can enable the network's function responsible for filtering all flows associated with that communication. This can be advantageous in cases where a compromised device, for example, sends flows to other devices without its knowledge.

[0066] As described above, according to a third aspect, the present invention also relates to a method for communication between an entity of a network and at least one device of the network, the method comprising: after the entity cannot determine whether a data stream to or from the device is associated with a network attack, the entity sending a message to the device proposing device cooperation to mitigate the network attack, the cooperation comprising, during at least one communication conducted by the device via the network according to a given transport protocol, the device performing at least one determined action, referred to as a cooperative action.

[0067] Relatedly, the present invention also relates to a network entity comprising a communication module triggered by the entity's inability to determine whether a data stream destined for or originating from a (first) device of the network is associated with a network attack. The communication module is configured to send a message to the device proposing device cooperation to mitigate the network attack. The cooperation includes the device performing at least one determined action, referred to as a cooperative action, during at least one communication conducted by the device via the network according to a given transport protocol.

[0068] The method for communication between entities in the network and the entities in the network benefit from the same advantages described above as the management method, the first device, the method for communication between the second device, and the second device according to the invention.

[0069] In one particular embodiment, the method for communicating by entities of the network further includes the step of receiving at least one piece of information that identifies at least one flow destined for and agreed to by the device, or identifies at least one flow destined for the device and considered by the device to be associated with a network attack.

[0070] This embodiment allows a first device to share knowledge about legitimate flows or, conversely, suspicious flows that it owns locally, with entities on the network, independently or not independently of its ongoing communications.

[0071] For example, this information can be provided in the following way:

[0072] • Provided in a blocking command (“drop” or “rate limit”) to block at least one flow that the device considers to be associated with a network attack; or

[0073] • Provided in the authorization command (“Accept”) to authorize the routing of the at least one flow agreed to by the device.

[0074] Furthermore, this embodiment enables the easy and rapid activation of mechanisms for filtering attack flows upstream of the first device at the network entity level.

[0075] In one particular embodiment, the method for communicating by entities of the network further includes the step of sending a request to the device to authorize routing at least one data stream identified in the request to the device.

[0076] This embodiment allows network entities to request explicit consent from a first device to route flows related to their communications.

[0077] In one particular embodiment, the method for communication by entities on the network further includes:

[0078] The step of receiving at least one data packet exchanged during the communication, the at least one data packet including at least one header indicating at least one piece of control information for the communication in unencrypted form, the at least one piece of control information being derived from the establishment status of the communication, the device's consent to send and / or receive data packets during the communication, and the device's consent or dis consent to the communication; and

[0079] • Steps to mitigate the cyberattack using at least one of the aforementioned control information.

[0080] In a particular embodiment of the present invention, the communication method and the management method are implemented by a computer.

[0081] The invention also relates to a computer program on a recording medium, which can be implemented in a computer or more generally in a first device according to the invention, and includes instructions designed to implement the management methods described above.

[0082] The invention also relates to a computer program on a recording medium, which can be implemented in a computer or more generally in a second device according to the invention, and includes instructions designed to implement the methods for communication by the second device as described above.

[0083] The invention also relates to a computer program on a recording medium, which can be implemented in a computer or more generally in an entity of a network according to the invention, and includes instructions designed to implement the methods for communication by entities of the network as described above.

[0084] Each of these programs can be written in any programming language and can be in the form of source code, object code, or intermediate code between source code and object code, such as in a partially compiled form, or in any other desired form.

[0085] The present invention also relates to a computer-readable information medium or recording medium comprising the computer program instructions as described above.

[0086] The information medium or recording medium can be any entity or device capable of storing programs. For example, the medium may include storage devices such as ROM (e.g., CD-ROM or microelectronic circuit ROM) or magnetic recording devices (e.g., hard disk or flash memory).

[0087] Furthermore, the information medium or recording medium can be a transmittable medium such as an electrical signal or an optical signal, which can be routed via a cable or optical fiber, a radio link, a wireless optical link, or other means.

[0088] The program according to the present invention can be downloaded specifically from a network such as the Internet.

[0089] Alternatively, the information medium or recording medium may be an integrated circuit in which a program is incorporated, the circuit being designed to perform or be used in performing the communication or management method according to the invention.

[0090] According to a fourth aspect, the present invention relates to a system comprising:

[0091] • At least one first device in the network according to the present invention;

[0092] • At least one second device capable of communicating with the first device; and

[0093] • At least one entity in the network;

[0094] The first device is configured to perform at least one determined action during at least one communication with the second device after detecting a cyberattack, in order to cooperate with the at least one entity to mitigate the cyberattack.

[0095] In one particular embodiment, the entity of the second device and / or network is according to the invention.

[0096] The system benefits from the same advantages described above as those of the communication and management methods, the first device and the second device, and the network entity according to the present invention.

[0097] In other embodiments, it is also conceivable that the communication and management methods, the first and second devices, the network entities and systems according to the present invention have combinations of all or some of the above features. Attached Figure Description

[0098] Other features and advantages of the invention will become apparent from the following description with reference to the accompanying drawings, which illustrate an exemplary embodiment of the invention in a manner that is by no means limiting. In the drawings:

[0099] [ Figure 1 [Already described] Figure 1 The structure of the short message header QUIC data packet is shown;

[0100] [ Figure 2 ] Figure 2 The system according to the invention is shown in its environment in a particular embodiment;

[0101] [ Figure 3 ] Figure 3 It schematically shows that it belongs to Figure 2 The system's hardware architecture for the devices and network entities according to the present invention;

[0102] [ Figure 4 ] Figure 4 The flowchart illustrates, in a specific embodiment, the process as described above. Figure 2 The main steps of the communication method according to the present invention implemented by the network entity of the system;

[0103] [ Figure 5 ] Figure 5 The flowchart is shown as in one particular embodiment. Figure 2 The main steps of the method for managing communications according to the present invention are implemented in one of the devices of the system.

[0104] [ Figure 6 ] Figure 6 The flowchart is shown as in one particular embodiment. Figure 2 The main steps of the communication method according to the invention are implemented by another device in the system;

[0105] [ Figure 7 ] Figure 7 An example is shown in a particular embodiment of the invention, where the short header of a QUIC data packet is modified to allow disclosure of control information;

[0106] [ Figure 8 ] Figure 8 An example is shown in which the long header of a QUIC data packet is modified to allow disclosure of control information in a particular embodiment of the invention; and

[0107] [ Figure 9 ] Figure 9 Two examples are shown of using control information carried by a modified QUIC data packet header in a particular embodiment of the invention. Detailed Implementation

[0108] Figure 2 The system 3 according to a particular embodiment of the invention is illustrated in its environment. System 3 enables cooperation to be established between one or more communication devices and one or more entities within a communication network NW involved in mitigating an ongoing cyberattack targeting or potentially affecting resources protected by said entities. This cooperation is implemented to manage communications transmitted via the network according to a given transport protocol, enabling the sharing of certain information between the equipment (communication devices and network entities) thereby contributing to the mitigation of cyberattacks.

[0109] In the embodiments described herein, the transport protocol considered is the QUIC transport protocol based on the UDP protocol. However, the invention is of course applicable to other transport protocols.

[0110] It should be noted that, for simplicity, a single network NW is considered here; however, the communication devices and / or network entities considered may be connected to or belong to different networks.

[0111] No restrictions are imposed on the nature of the communication devices considered. These devices can be user equipment (clients or servers, terminals, CPEs (representing "customer premises equipment"), digital decoders (or "set-top boxes"), etc.) (to which the network NW provides connectivity) or equipment of the network NW. "Communication devices" here are understood to mean devices capable of establishing communication with each other (hereinafter also referred to as connections in the context of the QUIC protocol). Here, these communication devices differ from entities located in the actual network, which reside on the communication paths between the communication devices, and through which the traffic exchanged between devices communicating along these paths is transmitted.

[0112] Similarly, no restrictions are imposed on the nature of the network NW, which can be a fixed or mobile network, regardless of its generation (e.g., 3G, 4G, 5G, 6G, etc.). In the embodiments described herein, it is assumed that the network NW implements the QUIC transport protocol.

[0113] No restrictions are attached regarding the nature of the ongoing cyberattacks that System 3 is working to mitigate, or the computing and / or network resources targeted by such attacks. For example, it could be a DDoS attack as described above, or an attack such as identity theft or ransomware, which could affect any type of resource, such as computing or memory resources, network resources (e.g., IP addresses, domain names, IP prefixes, etc.), and interconnection links with other networks.

[0114] exist Figure 2 In the hypothetical example, to mitigate an ongoing cyberattack ATTACK detected by the network NW (either directly or via an entity outside the network NW), system 3 relies on two communication devices 4 and 5, and network entity 6, which provides DPS services to prevent cyberattacks and protect the resources of the network NW. It should be noted that the cyberattack ATTACK does not necessarily directly target resources in the network NW protected by DPS entity 6 or communication devices 4 and 5. As mentioned above, the resources targeted by the cyberattack ATTACK can be of any type: equipment connected to devices 4 and 5 (if such equipment is, for example, a CPE), applications embedded in devices 4 and 5, all or some resources protected by DPS entity 6, etc. For example, it is possible that the resources protected by DPS entity 6 and / or devices 4 and 5 are not the direct target of the attack, but rather act as relays or enable it to reach the target of the attack.

[0115] It should also be noted that the present invention is applicable to other entities 6 in the network that are capable of performing functions other than preventing network attacks and play a direct or indirect role in mitigating ongoing network attacks. The present invention is generally applicable to any entity located in the network NW and configured to perform processing operations on traffic routed through that network, such as mitigation, filtering (e.g., firewalls), or even traffic classification (e.g., PCEF (Policy and Accounting Enforcement Function)).

[0116] In the embodiments described herein, devices 4 and 5, as well as network entity 6, are based on the present invention and have the hardware architecture of computer 7, such as Figure 3 The diagram is schematic. Devices 4 and 5 are configured herein to sometimes function as the first and second devices, respectively, within the context of this invention. It should be noted that they may function in this manner depending on whether they are the initiators of establishing communication and / or the intended recipients of communication.

[0117] Devices 4 and 5, and network entity 6, specifically include a processor 8, random access memory 9, read-only memory 10, non-volatile memory 11, and communication devices 12 that allow them, in particular, to communicate with each other. These communication devices 12 are based on wired or wireless communication interfaces, which are known in themselves and will not be described in detail here. Furthermore, in the embodiments described herein, the communication devices 12 are configured to implement the QUIC transport protocol and to send and receive data streams according to the QUIC protocol. Each stream includes one or more QUIC data packets, and each QUIC packet itself may include one or more QUIC frames. QUIC frames can be control frames (e.g., CONNECTION_CLOSE frames for closing a QUIC connection) or data frames (e.g., STREAM frames).

[0118] The read-only memory 10 of the computer 7 constitutes a recording medium according to the invention, which can be read by the processor 8 and on which one or more computer programs according to the invention are recorded.

[0119] More specifically, the read-only memory 10 of each of devices 4 and 5 includes records of two computer programs, PROG4 and PROG5.

[0120] Program PROG4 defines the functional modules of the first device within the scope of this invention, which depend on or control the aforementioned hardware components 8 to 12 of computer 7. Embodiments of these modules triggered upon detection of a network attack ATTACK are described herein (see...). Figure 2 This includes, in particular:

[0121] • Enable module 4A, configured to enable cooperation with at least one entity of the network NW (and particularly with DPS entity 6) on the first device to mitigate the network attack ATTACK. Enable module 4A is configured to perform at least one defined action, referred to as a cooperation action, during at least one communication conducted by the first device via the network NW according to a given transport protocol (QUIC in the example considered here);

[0122] • Transmit / receive module 4B, which is configured to send messages to and receive messages from other communication devices in the network NW. Such messages are described in more detail below.

[0123] Program PROG5 defines the functional modules of the second device within the scope of this invention, which depend on or control the aforementioned hardware components 8 to 12 of computer 7. Embodiments of these modules triggered upon detection of a network attack ATTACK are described herein (see [link to documentation]). Figure 2 This includes, in particular, a transmit / receive module (or more generally, a communication module) 5A, which is configured to:

[0124] • Receiving an information message from another communication device (the first device within the scope of this invention), the information message notifying the second device that the first device performed at least one defined cooperative action during at least one communication with the second device according to a given transmission protocol (QUIC in this hypothetical example); and

[0125] If the second device accepts to perform the collaborative action, it notifies the first device of its consent.

[0126] It should be noted that each of devices 4 and 5 can be a first device and a second device in the sense of the present invention, and the transmitting / receiving modules 4B and 5A can be combined together in a single module, which is appropriately configured to perform the functions of each of modules 4B and 5A.

[0127] The read-only memory 10 of DPS entity 6 includes a record of computer program PROG6. This program PROG6 defines functional modules of DPS entity 6 that depend on or control the aforementioned hardware components 8 to 12 of computer 7. Embodiments of these modules triggered upon detection of a network attack ATTACK are described herein (see [example description]). Figure 2 This includes, in particular:

[0128] • Network attack detection module 6A, used to detect network attacks against resources protected by DPS entity 6. This module 6A is equipped with means for analyzing traffic transmitted via DPS entity 6 and information fed back to it (where applicable) by third-party equipment connected to and / or outside the network NW;

[0129] • Network attack mitigation module 6B, used to mitigate network attacks detected by module 6A; and

[0130] • Communication module 6C, which is triggered when it detects that DPS entity 6 (especially its module 6A) cannot determine whether a data flow to or from a device in the network NW is associated with a network attack it has detected (e.g., in this case, a network attack ATTACK), is configured to send a message to the device proposing cooperation to mitigate the network attack. This cooperation includes the device performing at least one determined cooperative action during at least one communication conducted by the device via the network NW according to a given transport protocol (QUIC protocol in this hypothetical example).

[0131] Now refer to Figures 4 to 6 A description is given of how the collaboration between devices 4 and 5 and the network's DPS entity 6 is implemented in the embodiments described herein to mitigate an ongoing network attack (i.e., to attempt to deal with it and absorb it or at least reduce its consequences) (specifically, a network attack ATTACK). Figure 4 The main steps of the communication method according to the present invention are shown. In the embodiment described herein, the method is implemented by DPS entity 6 of network NW. Figure 5 The main steps of a method for managing communications according to the present invention are shown. In the embodiments described herein, the method is implemented by a communication device 4 during its communication, particularly during communication with a communication device 5. Figure 6 The main steps of the communication method according to the present invention are shown, and in the embodiment described herein, the method is implemented by a communication device 5.

[0132] There are no restrictions on the methods used to detect network attack ATTACKs (direct detection by DPS entity 6, detection by an entity outside the network NW that notifies DPS entity 6 of the situation, detection by communication devices, etc.) or which resources the network attack targets. It is assumed here that the attack may affect resources protected by DPS entity 6 (as described above, by using resources protected by DPS entity 6 as attack relays or to reach other resources, directly or indirectly), thus triggering intervention to mitigate it.

[0133] refer to Figure 4In the hypothetical example described here, after detecting a network attack ATTACK (step E10), DPS entity 6 analyzes the traffic exchanged via network NW and transmitted through the DPS entity via its module 6A (step E20). It is specifically assumed here that DPS entity 6 is located in network NW on the path used by communication of device 4, which is established here according to the QUIC transport protocol as described above. No restrictions are imposed on the nature of these communications: they can be one-sided or two-sided communications such as voice, multimedia data transmission, etc. These communications result in device 4 sending and / or receiving data streams via network NW, each data stream comprising a set of QUIC data packets. These data packets are encrypted according to the QUIC protocol: the QUIC protocol, as defined by the IETF, encrypts not only the payload data contained in these packets but also the connection control information (or communication control information, where connection refers to communication conducted according to the QUIC protocol), except for a small amount of said information (e.g., connection identifiers), as already referenced. Figure 1 The comments.

[0134] Therefore, DPS entity 6 here continuously analyzes traffic (i.e., data flows) destined for and originating from device 4 (hereinafter referred to as "associated with device 4") via its module 6A to determine whether it is affected by the network attack ATTACK (test step E30). It does this in a manner known per se, such as by checking whether the traffic originates from a known attack target, whether it exhibits suspicious characteristics (e.g., exceeding the capacity of the local link, the number of connections allocated to device 4 within a given time period being greater than the average typically observed within that time period or greater than a threshold, the number of "prototype" connections to device 4 being greater than a threshold, prototype connections corresponding to connections initiated by remote communication devices but without completing the sending of the messages required to confirm the connection, the thresholds considered being fixed based on knowledge of the attack ATTACK), etc. It should be noted that during this analysis, DPS entity 6's module 6A relies on statistical data it assesses, or on statistical data it receives from other entities capable of collecting such statistical data, based on "public" data it possesses regarding the traffic associated with device 4. It relies, for example, on connection (or communication) identifiers transmitted in unencrypted form in QUIC data packets to or from device 4, on traffic statistics collected by counters associated with the enabling of the SNMP (Simple Network Management Protocol) protocol for managing devices and networks, and on traffic statistics provided by counters associated with the enabling of the NETCONF (Network Configuration) protocol, etc.

[0135] If, during this analysis, DPS entity 6 is able to identify the traffic—that is, determine whether it is associated with an attack (response "Yes" in test step E30)—then DPS entity 6 appropriately processes the traffic based on that identification (step E40). Therefore:

[0136] If it determines that the traffic is associated with an attack ATTACK, it triggers one or more actions via its mitigation module 6B to mitigate the network attack ATTACK. Such mitigation actions are known in themselves and, of course, depend on the nature and extent of the network attack ATTACK, how the traffic associated with device 4 was compromised, etc. Such actions may include, for example, blocking the attack traffic (“dropping”), notifying other entities in the network NW to redirect legitimate traffic, dynamically establishing traffic receivers designed to disrupt the characteristics of the attack traffic, establishing “honeypots” designed to attract attack traffic to more easily redirect it to the traffic receivers, or preparing “abuse” documentation for the competent authorities (especially in cases of identity theft), etc.

[0137] If it determines that the traffic is legitimate (“clean”), it will route the traffic to its intended recipient.

[0138] Suppose that at a given time during this analysis, DPS entity 6 detects that it does not have the information needed to determine whether traffic originating from or destined for device 4 is associated with the network attack ATTACK (the response "No" in test step E30). For example, the traffic exhibits suspicious characteristics as described above, but DPS entity 6 cannot determine whether it is "legitimate" traffic or associated with the network attack ATTACK based on these characteristics.

[0139] According to the invention, DPS entity 6 then requests device 4 to switch to cooperative mode (step E50). For this purpose, in the embodiment described herein, DPS entity 6 sends a message to device 4 via its communication module 6C proposing the device's cooperation to mitigate network attack ATTACK (step E60). According to the invention, such cooperation includes device 4 performing one or more defined actions, referred to as cooperative actions.

[0140] More specifically, in the example envisioned here, the message sent by DPS entity 6 to device 4 is a QUIC control frame, referred to here for example as COMIT (for "cooperation relief"), and includes the following elements:

[0141] • The “Lifetime” parameter indicates the duration of the collaboration proposed by DPS entity 6; at the end of this period, device 4 can automatically deactivate the collaboration. It is assumed here that a default value (e.g., a value greater than or equal to 60 minutes) is defined for this parameter on each device 4, such that if the value of the “Lifetime” parameter is not explicitly indicated in the COMIT frame, the duration of the collaboration considered by device 4 is fixed to be at least equal to this default value;

[0142] The "Strategy_ID" parameter instructs DPS entity 6 to propose one or more cooperative actions to device 4 to help it mitigate the network attack ATTACK. These actions can be of various types and, in particular, include disclosing device 4's communication control information, disabling the use of an encrypted transport protocol (here, QUIC), or even freezing the migration of communication identifiers during device 4's communication (making it easier for DPS entity 6 to associate data streams with the same communication, etc.). Therefore, for example, in the context of the QUIC protocol, the "Strategy_ID" parameter can take the following values:

[0143] -0x0: Specifies the disclosure of communication (connection) control information;

[0144] -0x1: Specifies that the QUIC transport protocol is disabled during communication;

[0145] -0x2: Specifies to freeze the connection identifier (CID) during communication;

[0146] -0x3: Specifies to freeze connection identifiers and communication control information.

[0147] Of course, this list of actions is not exhaustive, and other actions can be envisioned. Multiple cooperative actions proposed by DPS entity 6 of the network can also be envisioned (see code 0x3 in the example given above). It can also be considered that, in the absence of an explicit "Strategy_ID" parameter in the COMIT frame, one or more default cooperative actions, specifically those corresponding to code 0x3 here, could be applied by device 4.

[0148] refer to Figure 5 Upon receiving a COMIT frame (step F10), in the embodiment described herein, device 4 has the option to accept or reject the cooperation requested by DPS entity 6 (test step F20). Even if the cooperation is initiated by DPS entity 6, device 4 is thus advantageously free to reject any cooperative action requested by the DPS entity. However, in another embodiment, it is conceivable that the COMIT frame may result in enabling cooperation on device 4 without requiring the explicit consent of the device.

[0149] If device 4 refuses to cooperate (response "No" in test step F20), it notifies DPS entity 6 of this situation or ignores the message (step F30).

[0150] If device 4 accepts cooperation (responding "Yes" in test step F20), device 4 stores the information contained in the COMIT frame (address of DPS entity 6, duration of cooperation, actions, etc.) in, for example, its non-volatile memory, and sends a cooperation confirmation message to DPS entity 6 (step F40). Then, cooperation is enabled within device 4 via its enabling module 4A, with a minimum duration equal to the duration indicated in the "Lifetime" parameter. It should be noted that this duration can be extended if necessary, for example, by DPS entity 6 if the network attack ATTACK is not absorbed by the end of the "Lifetime" duration.

[0151] As a variant, the COMIT frame does not include a "lifetime" parameter, has no defined default value, and can enable collaboration indefinitely until a message to end the collaboration is received from DPS entity 6.

[0152] Enabling cooperation on device 4 causes device 4 to perform the cooperative action proposed by DPS entity 6 in the COMIT frame.

[0153] Furthermore, during this collaboration, given that device 4 possesses local knowledge of its communications, it may also request DPS entity 6 or another entity in the network NW to inform it of data flows that the device agrees to and / or data flows that the device deems suspicious (in other words, associated with network attacks, particularly with network attack ATTACK). This can occur outside of any communications established by device 4.

[0154] For this purpose, in the embodiment described herein, device 4 sends a message to DPS entity 6, the message including information identifying at least one flow destined for and agreed to by device 4, or information identifying at least one flow destined for device 4 and considered by it to be associated with a network attack. Here, the message takes the form of one of the following commands, each of which can be associated, for example, with a dedicated QUIC control frame:

[0155] • A command called “DISCARD_ALL” is used to block (filter) all incoming communication to device 4 via DPS entity 6;

[0156] A command called “DISCARD_ALL / Except:ACCEPT_LIST(FLOW_ID)” is used by DPS entity 6 to block (filter) all incoming communication to device 4 except those identified by the flow identifier FLOW_ID provided in the list ACCEPT_LIST(FLOW_ID). The flow identifier can be filled with a connection identifier (CID) or other information used to identify the flow in question, such as source address, source port, etc.

[0157] • A command called “ACCEPT_ALL” is used to authorize DPS entity 6 to route all incoming communications of activity to device 4;

[0158] • A command called “ACCEPT_ALL / Except:DISCARD_LIST(FLOW_ID)” is used to authorize DPS entity 6 to route all incoming communications of activity to device 4 except those identified by the data flow identifier FLOW_ID provided in the list “DISCARD_LIST(FLOW_ID)”.

[0159] In another embodiment, DPS entity 6 itself may request device 4 to explicitly authorize the routing of one or more communications (or similarly, one or more data streams) to that device. To do this, it may send a message to the device, for example, in the form of a QUIC control frame (here referred to as CONSENT_CHECK), including the following parameters:

[0160] • The “FLOW_ID” parameter indicates an identifier for at least one communication (or connection), as indicated above. This identifier may be a connection identifier, source address, source port, etc.

[0161] • The “magic random number” parameter includes a randomly generated identifier that is intended to allow DPS entity 6 to associate the CONSENT_CHECK frame with the response to that frame sent by device 4.

[0162] Regardless of the variant implemented (“DISCARD / ACCEPT” command or CONSENT_CHECK message), DPS entity 6 stores the same filtering or routing rules as device 4 in its non-volatile memory and applies these rules to incoming communications to device 4 from then on.

[0163] The following describes how device 4 performs one or more cooperative actions requested by DPS entity 6 and as described in the COMIT frame in the embodiment contemplated herein. These actions may be performed within the framework of active or future QUIC communications between device 4 and other communicating devices, and depend on sending QUIC packets during these communications that contain information that may help DPS entity 6 mitigate network attack ATTACKs.

[0164] As a variation or supplement, this information may be sent by device 4 to DPS entity 6 via dedicated messages (or QUIC frames) provided for this purpose, in addition to communication performed by device 4 according to the QUIC protocol. These messages may be directed to DPS entity 6 or broadcast within the network at a predetermined address provided for this purpose, and may be shared, for example, by entities involved in the security of the network NW (e.g., IP multicast addresses reserved for this purpose, and which correspond to multicast groups subscribed to by entities of the network NW in question).

[0165] Such precautions allow device 4 to control the information it shares with the network and prevent the network from abusing the information disclosed to it for a limited period of time.

[0166] The collaborative action can be performed by device 4 during all or some of its communications. Therefore, in one embodiment, device 4 can determine which communications it applies the collaborative action to.

[0167] In the embodiment described herein, prior to executing a cooperative action, a negotiation phase is implemented between device 4, which has already agreed to cooperate with DPS entity 6 of network NW, and its communicators (in other words, devices that have already established communication with it), during which the device plans to execute the cooperative action (step F50). Here, device 4 executes the cooperative action conditionally upon the success of this negotiation phase (the response "yes" in test step F60): in other words, device 4 only executes the cooperative action during its communication if it receives approval from its communicators or if such approval is conditional. As a result, it is possible that device 4 applies the cooperative action only with some of its communicators.

[0168] For example, it is assumed here that such a negotiation phase is implemented by device 4 and device 5. Figure 6 The main steps implemented by device 5 during this negotiation phase are shown. These steps are performed within the framework of the communication method implemented by device 5 according to the present invention.

[0169] More specifically, in the embodiments described herein, during the negotiation phase, device 4 sends a message to device 5 notifying it of one or more cooperative actions to be performed during communication with device 5. This information message is received by device 5 via its send / receive module 5A. It is here in the form of a QUIC frame and encrypted according to the principles of the QUIC protocol. In the embodiments described herein, the information message sent by device 4 depends on the cooperative action performed by device 4 (depending on the different frames of the action) and includes one or more execution conditions for the cooperative action.

[0170] Therefore, for example, if the cooperative action performed by device 4 is to disclose control information about communication with device 4, the information message sent by device 4 is a QUIC frame (here referred to as CONTROL_REVEAL) and specifically includes the following parameters to specify the conditions for disclosing control information:

[0171] The "Lifetime" parameter, as in the COMIT frame, indicates the duration of the collaboration implemented by device 4. If the "Lifetime" parameter is not set in the CONTROL_REVEAL frame, it can be assumed that device 4 will apply a default value, such as greater than or equal to 60 minutes; and

[0172] The "Direction" parameter indicates the communication direction affected by the cooperative action performed by device 4. For example, this parameter can take the following values:

[0173] -0x0: Only data packets sent by device 4 are affected by the control information disclosure;

[0174] -0x1: Only data packets sent by remote device 5 are affected by the disclosure of control information;

[0175] -0x2: All data packets sent by devices 4 and 5 are subject to control information disclosure. This is assumed to be the default option if no value is specified for the "direction" parameter in the CONTROL_REVEAL frame.

[0176] Of course, these parameters are given as examples only, and other execution conditions can be specified. For example, only packets that share the same given destination address, the same given source address, the same source or destination port number, or a combination of these criteria and are sent by device 4 (or device 5 respectively) will be affected by control information disclosure, etc.

[0177] Device 5 can then accept or reject (e.g., by ignoring the CONTROL_REVEAL message, step G40) the collaboration implemented by device 4 (test step G20). As a variant, negotiation of one or more execution conditions for a collaborative action can be triggered between the two devices. Acceptance or rejection of collaboration ends the negotiation phase.

[0178] This assumes that device 5 accepts cooperation (responding "Yes" in test step G20 and "Yes" in step F60), and the execution of the cooperation action includes disclosing control information for its communication with device 4. Device 5 then sends an acknowledgment message to device 4 to notify the latter of its consent (step G30). This acknowledgment message is received by device 4 via its transmit / receive module 4B.

[0179] It should be noted that devices 4 and 5 can be independently requested to cooperate by DPS entity 6 or different entities in network NW, or even by different entities in their respective networks if the two devices belong to different networks. For example, if devices 4 and 5 have already accepted such cooperation, they can send QUIC CONTROL_REVEAL frames to each other through the same communication.

[0180] The negotiation phase just described is performed for existing QUIC communication (or connection) of device 4; in other words, it is performed for communication that has already been established. A similar negotiation phase can also be performed for future QUIC communication of device 4 (that is, those established after a trigger event has been received / detected).

[0181] Therefore, when device 4 sends a request to establish QUIC communication to a remote device (e.g., device 5), it uses a QUIC frame that discloses communication control information. It also sends a CONTROL_REVEAL frame during the establishment request to inform device 5 of the execution conditions (e.g., duration, direction) for cooperative actions. Device 5 processes the CONTROL_REVEAL frame in the same way as described above for ongoing communication. Therefore, it should be noted that negotiation is secondary for future communication, and the disclosure of communication control information in the communication establishment request is not objected to.

[0182] When the negotiation phase results in the remote device (device 5 in the example above) accepting cooperation, device 4 can therefore continue to disclose control information related to these communications during its communication with device 5, for the duration defined by the "lifetime" parameter and in accordance with the execution conditions negotiated with device 5. Figure 5 Step F70 in the middle.

[0183] In the embodiments described herein, communication control information is disclosed in the common header of QUIC data packets sent and / or received by device 4. Functions located in the network NW through which these QUIC data packets are transmitted (typically, in the example contemplated herein, DPS entity 6) are thus able to access the control information disclosed by device 4 (and / or its communicators).

[0184] More specifically, in the embodiments described herein, the inventors propose modifying the common portion of the header of QUIC packets currently defined in the QUIC protocol to explicitly indicate communication control information in unencrypted form. Such information would be, for example:

[0185] • The establishment status of this communication;

[0186] • One and / or the other device involved in the communication (devices 4 and 5 in this hypothetical example) agree to send and / or receive data packets during the communication; and

[0187] • One and / or the other of the devices involved in the communication (devices 4 and 5 in the hypothetical example here) agree or disagree with the communication.

[0188] Figure 7 This example demonstrates such a modification to the short message header of a QUIC packet. In this example, the first byte of the short message header (see...) Figure 1 The (reserved) flag C in byte 1-1 shown is set to "1" to indicate that the QUIC packet contains a new field (here referred to as "common control state"), which reflects various communication control information (in the current prior art, the reserved flag C is typically set to 0; if it is set to 1, it is ignored). The "common control state" field can be filled with, for example, the following values:

[0189] · 0x0: Indicates that communication (or connection) is currently being established;

[0190] ·0x1: Indicates that device 4 agrees to receive data packets from a remote device (device 5 in this hypothetical example);

[0191] ·0x2: Used to indicate that device 4 agrees to send and receive data packets;

[0192] ·0x3: Used to indicate communication established with the mutual consent of devices 4 and 5; and

[0193] ·0x4: Used to indicate communication of disagreement.

[0194] It should be noted that in the prior art, communications that devices disagree with are typically ignored. Instead, the inventors propose to use this information advantageously and bring it to the attention of one or more functions of the network NW (e.g., DPS entity 6 here), which can then be responsible for filtering all flows related to such communications that device 4 disagrees with (or even all flows related to communications established with remote device 5).

[0195] Of course, other values ​​can be envisioned as variations to provide additional communication control information to network entities involved in mitigating ATTACK attacks. However, it should be noted that disclosing communication control substates (such as the creation or closure of new channels or STREAMs, retransmission of QUIC packets, etc.) appears to be useless, as this information cannot be used in advance by such network entities.

[0196] like Figure 8 As shown, as a variant, it is also conceivable to modify the long header to include a new "Common Control Status" field. For the group Initial (by... Figure 8 B (shown) and 0-RTT (by B) Figure 8 (Example A) This field is set to "0x0". The advantage of this variant is that it allows network functions to detect connections established in cooperative mode in advance. The function can therefore store identifiers CID (source and destination) in memory to associate the characteristics of sent packets with those of received packets in the same QUIC communication.

[0197] It should be noted that, in order to prevent the introduction of reflection attacks into the network NW through the cooperation implemented between device 4 and DPS entity 6, the communication devices involved in the communication transmitted via DPS entity 6 can be configured such that they do not send more than three QUIC packets that disclose the control information of the communication.

[0198] Figure 9 The illustration shows an exemplary use by a network entity (e.g., DPS entity 6 here) of control information disclosed in the header of a QUIC packet exchanged between devices 4 and 5 to mitigate network attacks.

[0199] refer to Figure 9 A, at the origin of device 4, the characteristic of the agreed cooperative communication is that DPS entity 6 observes the following elements:

[0200] • Send a (QUIC1) QUIC communication initialization message from device 4 to device 5: In this message, flag C is set to 1, and the "Common Control Status" field (or PCS in the diagram) is set to PCS = 0x0 (or 0). The connection identifier (SCID or source CID) of device 4 is set to Val4, while the connection identifier (DCID) of remote device 5 is set to 0;

[0201] • Device 5 sends a (QUIC 2)QUIC message to Device 4, where the flag C is set to 1 and the "Common Control State" field is set to PCS=0x1 (reflecting the sending or receiving of consent information);

[0202] • Device 4 sends a (QUIC 3) QUIC message to device 5, where the flag C is set to 1 and the "Common Control State" field is set to PCS=0x2 (reflecting the packet sending and receiving consent information);

[0203] • Device 5 sends (QUIC4) and (QUIC5) QUIC messages to Device 4, and Device 4 sends them to Device 5, where the flag C is set to 1 and the "Common Control State" field is set to PCS=0x03 (reflecting communication established under mutual agreement).

[0204] A similar exchange can be described for communication initiated by device 5.

[0205] If no consent message is exchanged between the two devices (corresponding to the "Common Control State" field set to 0x3), or if device 4 does not explicitly indicate its consent to receive traffic as part of the communication established with device 5, then DPS entity 6 located on the path of the exchange that occurs between devices 4 and 5 can detect anomalies in traffic destined for or originating from device 4.

[0206] If such an anomaly is detected, DPS entity 6 may decide to redirect the data packets of the communication to a cleanup center for processing these data packets or to block these data packets.

[0207] according to Figure 9 In another example shown in B, after receiving various data packets from device 5 (sent (QUIC6) and (QUIC7)), device 4 can send a QUIC message with the "Common Control State" field set to PCS=0x4 (sent (QUIC8)). This message is intercepted by DPS entity 6, which extracts communication control information from it and then deletes the message. All packets of this communication, or even all packets of communication received from device 5, are then blocked and rejected by DPS entity 6 (rejected sending (QUIC9) and (QUIC10)). These filters can be removed after a certain period expires. It should be noted that, preferably, the message intercepted by DPS entity 6 is not routed to device 5 to prevent the device from using it to change its attack strategy.

[0208] Regarding these two examples, it is clear that disclosing control information within the framework of the QUIC protocol advantageously allows DPS entity 6 to better distinguish between traffic agreed to by device 4 and attack traffic, and to take appropriate and effective actions to mitigate the attack.

[0209] As described above, in addition to disclosing communication control information, DPS entity 6 may also propose other cooperative actions to device 4 (and, where applicable, to device 5), and in particular, freeze the migration of the communication identifier during communication established by device 4 (corresponding to the "Strategy_ID" parameter set to 0x2 in the COMIT frame sent by DPS entity 6 to device 4).

[0210] For this action, it is also conceivable that after device 4 accepts the collaboration proposed by DPS entity 6, a negotiation phase will be implemented between device 4 and 5.

[0211] In a manner known per se, the QUIC protocol provides communication devices with the possibility of changing the communication identifiers (more commonly referred to as connection identifiers or CIDs in the context of the QUIC protocol) they use to characterize said communication during their communication. This change (also known as a “connection identifier migration”) is typically performed by exchanging QUIC frames provided for this purpose, and the content of the frames is encrypted, specifically the connection identifier to which the communication is to be migrated, making it impossible for network entities to establish a connection between the new connection identifier used after the communication device migration and the previous connection identifier used before the migration. This invention provides the possibility of freezing the migration of the connection identifier associated with the communication for a defined duration, which may be equal to the value of the “lifetime” parameter provided in the COMIT frame, or, as a variant, correspond to the duration for which the communication will continue.

[0212] By maintaining the same connection identifier throughout the duration of QUIC communication, the classification of data packet characteristics for this communication by network functions such as DPS Entity 6 is simplified, as this allows for the association of packets sent and received during the same communication. Therefore, the same communication is uniquely identified when one or more mitigation actions are in progress. DPS Entity 6's analysis of packets (to determine whether they belong to traffic agreed upon by Device 4 or attack traffic) is thus greatly simplified.

[0213] Regarding the disclosure of control information, before the application freezes the migration of connection identifiers related to its ongoing communication, device 4 can initiate a negotiation phase with its communicator (especially with device 5). Figure 5 Step F50, Figure 6 Steps G10 and G20).

[0214] To this end, device 4 sends a message to device 5 informing the latter of its plan to freeze the connection identifier. This message takes the form of an encrypted QUIC frame called FREEZE_CID and specifically includes a “lifetime” parameter indicating the duration for which device 4 plans to maintain the unique connection identifier CID during its communication with device 5. Preferably, the “lifetime” duration is selected such that the connection identifier CID remains the same throughout the communication (it should be noted that, therefore, the “lifetime” duration used to maintain the connection identifier CID does not necessarily correspond to the enabled duration of cooperation provided by DPS entity 6 in the COMIT message. In particular, it can be less than the duration provided in the COMIT message).

[0215] As a variant, the FREEZE_CID frame may contain other parameters. Therefore, in a manner known to those skilled in the art, the connection identifier CID comprises two parts: a source connection identifier or SCID and a destination connection identifier or DCID. As an execution condition, the FREEZE_CID frame may indicate the portion of maintenance recommended by the cooperative action to be applied.

[0216] At the end of the "lifetime" period, collaboration is automatically disabled on device 4. Then, if necessary, device 4 can generate a new connection identifier and migrate the connection identifier using known QUIC frames NEW_CONNECTION_ID and RETIRE_CONNECTION_ID, according to the conventional QUIC protocol mechanism known to those skilled in the art.

[0217] Remote device 5 can accept (responding "yes" in test step G20) or reject (responding "no" in test step G20) the freezing of the connection identifier by responding with an ACK message (step G30) or by ignoring the FREEZE_CID message (step G40).

[0218] Once the negotiation phase is successfully completed, the two devices 4 and 5 maintain one and only one connection identifier (CID), which is formed by the connection identifier generated by device 4 and the connection identifier generated by device 5 (which alternately serve as SCID and DCID depending on the direction of the messages exchanged during communication) (steps G50 and F70).

[0219] It should be noted that when DPS entity 6 proposes a combination of multiple cooperative actions in its COMIT message (e.g., setting the "Strategy_ID" parameter to 0x3 to request freezing the connection identifier and disclosing control information), a negotiation phase similar to or the same as the negotiation phase just described for cooperative actions such as disclosing control information and freezing the connection identifier can also be implemented. In this case, during the negotiation phase, remote device 5 can accept or reject one or more of these cooperative actions.

[0220] As described above, for device 4, another possible cooperative action could include disabling the QUIC transport protocol to establish its communication, and using a transport protocol other than QUIC (such as TCP) to establish its future communication (i.e., communication established after a triggering event has been received / detected). As for other cooperative actions, prior negotiation could be implemented between device 4 and its communicators to ensure that the communicators accept disabling the QUIC protocol.

[0221] After accepting the collaboration proposed by DPS entity 6, and where applicable, if its communicator agrees, device 4 uses the TCP protocol to establish its new communication as long as the collaboration is active. At the end of the collaboration (in other words, at the end of its "lifetime"), device 4 may reuse the QUIC protocol to establish communication with its communicator.

[0222] The collaborative actions just mentioned are not restrictive in themselves. They are preferably applied within the framework of the QUIC protocol, but are not limited to it. Furthermore, other collaborative actions can certainly be envisioned as variations or supplements to those actions just cited and described.

[0223] Furthermore, in the embodiments described herein, the collaboration between device 4 and the network NW (more specifically, with DPS entity 6) is triggered by DPS entity 6. As a variant, the collaboration can be triggered by device 4 itself. In this case, device 4 does not receive explicit messages from the network, but instead relies on events it observes locally (e.g., an attack is detected) or events reported to it by remote devices or third-party entities (whether outside or not within the network).

[0224] In this embodiment, by default, cooperation involves all QUIC communications conducted by device 4 via network NW. However, device 4 may decide at any time to enable cooperation only for a subset of its communications, for example, based on the nature of events reported by its communicators or the network used to route the communication data.

[0225] Furthermore, it should be noted that in the embodiments described herein, device 4 is connected to only a single network NW and is requested by only a single network function (specifically, DPS entity 6). As a variation, the same device may connect to multiple different networks and decide to enable collaboration with one or more different entities on these networks.

Claims

1. A method for managing communications by a first device (4) of a network according to a given transport protocol, said method being implemented by this first device and comprising: after detecting a network attack (E10), a step of enabling (F40) on said first device a collaboration with at least one entity of said network to mitigate said network attack, said collaboration comprising, during at least one of said communications by said first device according to said given transport protocol via said network, performing (F70) by said first device at least one determined action, referred to as a collaboration action, wherein at least one collaboration action comprises at least one of: disclosing control information for encryption of said at least one communication; freezing migration of a communication identifier used during said at least one communication; deactivating, during said at least one communication, use of said given transport protocol by said first device.

2. The method of claim 1, wherein, said enabling step being triggered by receiving (F10) from said at least one entity of the network a message proposing said collaboration.

3. The method of claim 1, further comprising a step of sending (F50) to at least one second device (5) participating in at least one of said communications with said first device according to said given transport protocol, an information message informing said second device of the performance by this first device of said at least one collaboration action.

4. The method of claim 3, wherein, Performance of said at least one collaboration action is conditional on receiving consent from this second device.

5. The method of claim 3, wherein, said information message comprises at least one execution condition of said collaboration action.

6. The method of any one of claims 1 to 5, wherein, This at least one control information comes from: a status of establishment of said communication; consent to send and / or receive data packets during said communication; and consent or non-consent to said communication.

7. The method of any one of claims 1 to 5, wherein, said at least one collaboration action is performed for a determined duration.

8. The method of any one of claims 1 to 5, wherein, said given transport protocol is the QUIC protocol.

9. A method for communicating with a first device (4) of a network, said method being implemented by a second device (5) and comprising: a step of receiving (G10) from this first device an information message informing this second device of the performance by this first device of at least one determined action, referred to as a collaboration action, during at least one communication with this second device according to a given transport protocol and allowing collaboration with at least one entity of the network to mitigate a network attack; a step of informing (G30) this first device of its consent if said second device accepts to perform said collaboration action, wherein at least one collaboration action comprises at least one of: disclosing control information for encryption of said at least one communication; freezing migration of a communication identifier used during said at least one communication; deactivating, during said at least one communication, use of said given transport protocol by said first device.

10. The method of claim 9, wherein, at least one data packet exchanged during said communication according to said given transport protocol comprises at least one header indicating in unencrypted form at least one control information for said communication, this at least one control information coming from: a status of establishment of said communication; consent to send and / or receive data packets during said communication; and consent or non-consent to said communication. agreeing or disagreeing with the communication.

11. The method of claim 9 or 10, wherein, performing the at least one cooperative action for a determined duration.

12. The method of claim 9 or 10, wherein, the given transport protocol is the QUIC protocol.

13. A method for communicating, by an entity (6) of a network, with at least one device of the network, the method comprising: after the entity is unable to determine whether a data flow to or originating from the device is associated with a network attack, a step of sending (E60), by the entity, to the device, a message proposing a device cooperation to mitigate the network attack, the cooperation comprising, during at least one communication by the device via the network according to a given transport protocol, performing, by the device, at least one determined action, referred to as a cooperative action, wherein at least one cooperative action comprises at least one of: disclosing control information for encryption of the at least one communication; freezing migration of a communication identifier used during the at least one communication; suspending, during the at least one communication, use of the given transport protocol by the device.

14. The method of claim 13, further comprising a step of receiving at least one item of information identifying at least one flow to the device and agreed by the device, or at least one flow to the device and considered by the device as being associated with a network attack.

15. The method of claim 14, wherein, the at least one item of information is provided: in a blocking command, so as to block, by the entity, the at least one flow considered by the device as being associated with a network attack; or in an authorization command, so as to authorize routing of the at least one flow agreed by the device.

16. The method of claim 13, further comprising a step of sending a request to the device to authorize routing of at least one data flow identified in the request to the device.

17. The method of claim 13, wherein the at least one data packet comprises at least one header in which at least one item of control information for the communication is indicated in unencrypted form, the at least one item of control information being from among an establishment status of the communication, the device agreeing to send and / or receive data packets during the communication, and the device agreeing or disagreeing with the communication.

18. The method of claim 17, further comprising: a step of using the at least one item of control information to mitigate the network attack.

19. The method of any one of claims 13 to 18, wherein, performing the at least one cooperative action for a determined duration.

20. The method of any one of claims 13 to 18, wherein, the given transport protocol is the QUIC protocol.

21. A computer storage medium comprising a program (PROG4, PROG5, PROG6) comprising instructions for executing the method of any one of claims 1 to 20 when the program is executed by a computer.

22. A device (4) belonging to a network, comprising an enabling module, triggered after detection of a cyber attack, and configured to enable, on said device, a collaboration with at least one entity of the network to mitigate said cyber attack, said enabling module (4A) being configured to perform, during said collaboration, at least one determined action, referred to as a collaboration action, during at least one communication of said device via said network according to a given transport protocol, wherein, at least one cooperative action comprises at least one of: disclosing control information for encryption of the at least one communication; freezing migration of a communication identifier used during the at least one communication; suspending, during the at least one communication, use of the given transport protocol by the device.

23. A communication device (5), referred to as a second device, comprising a communication module (5A) for communicating with a first device of a network, said communication module being configured to: receive, from the first device, an information message informing the second device of at least one determined action to be performed by the first device during at least one communication with the second device according to a given transmission protocol, said action being referred to as a collaborative action and allowing to collaborate with at least one entity of said network in order to mitigate a network attack; if the second device accepts to perform the collaborative action, the first device is informed of its agreement, wherein the at least one collaborative action comprising at least one of: disclosing control information for encryption of said at least one communication; freezing migration of a communication identifier used during said at least one communication; deactivating, during said at least one communication, use of said given transmission protocol by said device.

24. An entity (6) of a network, comprising a communication module (6C) triggered by said entity being unable to determine whether a data flow to or originating from a device of the network is associated with a network attack, said communication module being configured to: sending a message to the device proposing a device collaboration to mitigate the network attack, the collaboration comprising at least one determined action, referred to as a collaboration action, to be performed by the device during at least one communication by the device via the network according to a given transmission protocol, wherein, the at least one collaborative action comprising at least one of: disclosing control information for encryption of said at least one communication; freezing migration of a communication identifier used during said at least one communication; deactivating, during said at least one communication, use of said given transmission protocol by said device.

25. A communication system (3), comprising: at least one first device (4) of a network as claimed in claim 22; at least one second device (5) able to communicate with the first device; and at least one entity (6) of the network; said first device being configured to perform, after detecting a network attack, at least one determined action during at least one communication with the second device in order to collaborate with said at least one entity in order to mitigate said network attack.

26. The communication system (3) of claim 25, wherein the second device comprising a first communication module (5A) for communicating with a first device of a network, said first communication module being configured to: receive, from the first device, an information message informing the second device of at least one determined action to be performed by the first device during at least one communication with the second device according to a given transmission protocol, said action being referred to as a collaborative action and allowing to collaborate with at least one entity of said network in order to mitigate a network attack; if said second device accepts to perform said collaborative action, informing the first device of its agreement.

27. The communication system (3) of claim 25, wherein, the entity of the network comprising a second communication module (6C) triggered by said entity being unable to determine whether a data flow to or originating from a device of the network is associated with a network attack, said second communication module being configured to send to said device a message proposing a device collaboration to mitigate said network attack, said collaboration comprising, during at least one communication by the device with the network according to a given transmission protocol, at least one determined action to be performed by the device, this action being referred to as a collaborative action.

Images