Method for managing a set of IP addresses, collaboration method, and devices configured to implement these methods

Abstract

The management method comprises: - detecting suspicious behaviour associated with an IP address of a first set of IP addresses selected by a first device (CGN#1) of a network to process at least one packet of a client equipment served by the first device; - carrying out at least one action among: - adjustment of at least one level of sharing of at least one IP address of the first set, applied by the first device; - asking at least one second device (CGN#2) managing a second set of IP addresses to delegate at least one IP address of the second set to the first device so that it is able to select this delegated IP address to process at least one packet of at least one client equipment served by the first device.

Description

Description Title of the invention: Method for managing a set of IP addresses, collaboration method and devices configured to implement these methods. Prior art

[0001] The invention belongs to the general field of telecommunications.

[0002] It concerns the management of a connectivity service, more particularly in the event of computer attacks in a telecommunications network, such as for example denial of service attacks (or DDoS for "Distributed Denial of Service" in English).

[0003] As is well known, a DDoS attack is an attempt to make resources (e.g. computing resources or network resources) unavailable to their users. Such attacks can be massive and likely to compromise several hundred thousand client devices (e.g. terminals), which can in turn be used as relays to amplify the harmful power of the attacks. These attacks are becoming increasingly frequent and intense; their scale in terms of duration but also scope and propagation makes it difficult for the DPS (DDoS Protection Service) service(s) deployed in the network to detect and mitigate such attacks (e.g. by quarantining the resources targeted by the attacks, filtering traffic associated with an attack, etc.).

[0004] Furthermore, implementing mitigation actions within a network is particularly problematic in the presence of address translation devices also called NAT (for "Network Address Translation" in English) operators (or CGN for "Carrier Grade NAT" in English, or LSN for "Large Scale NAT" in English).

[0005] An operator NAT is a device implementing a translation function (also called translation) of IP addresses (and, where applicable, port numbers) in an operator network. Several types of operator NAT have been specified by the IETF (for "Internet Engineering Task Force") and deployed by operators (for example, NAT 4, NAT64, DS-Lite, NPTv6, etc.). For example, in a so-called double NAT architecture, the NAT function of a CGN is added to the NAT function embedded in the customer network access equipment (for example, in a CPE for "Customer Premises Equipment"). Network architectures based on the use of CGNs make it possible, in particular, to implement an IP address sharing mechanism, offering, for example, a service continuity solution in a context of IPv4 address shortage.

[0006] For example, a so-called "internal" address (for example a private address in the case of double NAT engineering) is assigned instead of another address, called "external" (for example a global IPv4 address in the case of double NAT engineering, in particular) to the connection interface of the access equipment (for example a CPE) of the customer to the network. The translation of the internal address assigned to the connection interface of the access equipment into an external address is carried out by the operator NAT (CGN). Figure 1 illustrates, on an example, the different address translations carried out respectively by a CPE1 access equipment and by a NAT CGN2 operator on IP data packets sent by an H3 terminal, connected for example to a corporate network or a home network, and intended for remote S4 equipment.

[0007] Thus, in the example of Figure 1, an IP data packet P with a source IP address of 10.2.25.5 and a source port number of 12345 is sent by the terminal H and received by the access device CPE1. It is assumed here that the private IP address 192.168.1.56 and the port number 16587 are assigned to the WAN (Wide Area Network) interface of the access device CPE1 in the case of double NAT engineering. The NAT function of the access device CPE1 then replaces the pair (10.2.25.5,12345) with the pair (192.168.1.56,16587) in the header of the IP data packet P received from the terminal H3. It can also make other modifications, such as executing a cyclic redundancy code (CRC, more commonly referred to as a "checksum" in English) or applying an ALG (Application Level Gateway) type function.Then the access equipment CPE1 sends the IP data packet P', at least the source address field of which has been modified after execution of the NAT function, to a CGN2 operator NAT. Upon receipt of the IP data packet P', the CGN2 operator NAT selects an external IP address (e.g. a public IPv4 address) and an external port number (e.g. a public port number) for processing the packet P', for example the pair (1.2.3.4, 45875), and associates in an information base, for example a BIB (for "Binding Information Base") the pair (1.2.3.4, 45875) with the pair (192.168.1.56, 16587) as well as the transport protocol used (not mentioned in Figure 1 for the sake of simplification). Then the CGN2 operator NAT replaces in the header of the IP data packet P', the internal IP address 192.168.1.56 and the internal port number 16587, with the external IP address 1.2.3.4 and the external port number 45875 respectively.The resulting IP data packet P" is then transferred by the operator NAT CGN2 to its destination (the remote equipment S4 in the figure).

[0008] It should be noted that the shortage of IPv4 addresses is also a problem encountered in mobile networks, due to the limitation of the private address space (18 million addresses available in total). Indeed, current mobile network engineering tends to almost systematically assign a private IPv4 address to each mobile terminal. Operators implementing such engineering must therefore also implement private IPv4 address sharing mechanisms based on operator NAT (CGN) typically deployed at the Gi interface (sGi or N6 depending on the 3GPP release considered) allowing a mobile access network to be connected to the data network (for example, the Internet).In addition, NAT64-type conversion mechanisms can also be deployed in the networks of operators that have defined a migration strategy to IPv6, a protocol whose address space is presented as the sustainable solution to the shortage of IPv4 addresses. Such a NAT64 address translation mechanism advantageously allows an IPv6-only node supporting only the IPv6 protocol to communicate with an IPv4-only node supporting only the IPv4 protocol, by converting the IPv6 data packets received from the IPv6-only node into IPv4 packets before transmitting them to the IPv4-only node.

[0009] RFC 6269, published by the IETF, lists a set of problems inherent to address sharing solutions. Typically, in an attack mitigation context, quarantining an IP address associated with a DDoS attack impacts all client devices sharing this address. Implementing mitigation actions in a network or by a remote server may therefore impact the quality of service perceived by all client devices sharing the same IP address, or even make the service unavailable for some. Statement of the invention

[0010] The invention makes it possible in particular to improve the effectiveness of attack mitigation policies in network environments where functions that aggregate several connections using addresses that may be shared (for example CGN or proxy functions) are deployed, by proposing a method for managing, by a first device located in a network, a first set of IP addresses, this method comprising: a step of detecting suspicious behavior associated with an IP address of the first set selected by the first device to process at least one data packet from a client equipment served by the first device; following said detection, a step of executing at least one action from: o an adjustment of at least one sharing rate of at least one IP address of the first set applied by the first device;and o a request, addressed to at least one second device managing a second set of IP addresses, to delegate at least one IP address from the second set to the first device so that the first device can select said at least one delegated IP address to process at least one data packet from at least one client device served by the first device.;

[0011] Correlatively, the invention also relates to a device, called the first device, located in a network, this first device managing a first set of IP addresses and comprising: a detection module, configured to detect suspicious behavior associated with an IP address of said first set selected by the first device to process at least one data packet from a client equipment served by the first device; an execution module, configured to execute following said detection, at least one action from: o an adjustment of at least one sharing rate of at least one IP address of the first set applied by the first device;and o a request, addressed to at least one second device managing a second set of IP addresses, to delegate at least one IP address from the second set to the first device so that the first device can select said at least one delegated IP address to process at least one data packet from at least one client device served by the first device.;

[0012] The first and second devices may typically be operator NATs (or CGNs or LSNs) as described above, configured to manage separate pools of IP addresses (address sets within the meaning of the invention) that may be shared between several client devices connected to a network. The two devices may be co-located or embedded in separate devices, be deployed in the network in a distributed or centralized manner, the network being able to comprise several successive levels of operator NAT. The IP addresses of the same pool can be IPv4 addresses and / or IPv6 addresses, contiguous or not. The invention applies to any type of operator NAT (for example, NAT44, NAT64, DS-lite, NPTv6 (i.e. implementing a translation of IPv6 network prefixes into other IPv6 prefixes), etc.). Furthermore, no assumption is made as to the nature of the client equipment likely to share the same IP address: it can be terminals, equipment for accessing an operator's network such as a CPE, etc.

[0013] The invention may also be applied in other contexts, and in particular to other devices managing a plurality of IP addresses that may be shared between several client devices, such as, for example, devices implementing a proxy function using its own IP addresses to relay received data packets. Such devices are for example described in sections 5, 6 and 7 of the document RFC 7620 published by the IETF and entitled "Scenarios with Host Identification Complications", August 2015. Furthermore, the invention also applies when the IP addresses managed by the first and / or second devices are allocated at a given time to unique client devices, i.e. to IP addresses that are not shared between several client devices.

[0014] The IP addresses managed by the first and second devices, as well as the delegated IP addresses, are used by said devices to process data packets from client equipment. By "packet from a client equipment" is meant a packet (or equivalently a message) containing data sent by this client equipment and intended for a recipient entity, or conversely, sent by a source entity and intended for the client equipment. It should be noted that, within the meaning of the invention, the packet in question may be received by the first device directly from the client equipment or transit via one or more intermediate equipment (for example via one or more operator NATs when several levels of operator NAT are deployed in cascade in the network) before being received by the first device.

[0015] Thus, the invention proposes, in order to effectively respond to the detection of suspicious behavior associated with an IP address (for example suspicious activity sent with this address as the source address) in a network in which the IP addresses are likely to be shared between several client devices, to implement two types of actions (in an alternative or combined manner), namely: modifying one or more address sharing rates applied by the device (first device within the meaning of the invention) managing the IP address with the suspicious behavior: typically, the first device can reduce the sharing rate applied to the IP address with the suspicious behavior and increase that of the other IP addresses that it manages in order to be able to allocate these other IP addresses to the client devices that it serves (current and future);benefit from the assistance of another device (second device within the meaning of the invention), and in particular ask it to delegate one or more “healthy” IP addresses to it so that it can use them to process packets from the client equipment attached to it. In this way, the “nominal” set of IP addresses (first set within the meaning of the invention) assigned to the first device is de facto extended with new IP addresses.;

[0016] These actions aim to ensure the availability of "healthy" IP addresses (i.e. not known to have been used for fraudulent purposes and which are therefore not a priori targeted as targets or used by the source of an attack) so that it is able to process the client equipment packets which reach it, despite the malicious behavior associated with one of the active IP addresses which the first device (CGN, for example) manages. These actions may, in a particular embodiment, have an effect for a limited period of time, for example as long as the suspicious behavior associated with the IP address in question persists.

[0017] By performing such actions, the impact of computer attacks on the operation of the service(s) subscribed to by users of client equipment that may share the same IP address is reduced. It should be noted that IP address sharing is often carried out in the network without the users' knowledge. For example, as mentioned above, it may be implemented by a network operator to compensate for the shortage of IPv4 addresses. The invention makes it possible to ensure that this sharing of IP addresses remains transparent to users and does not impact the quality of service experienced by them. The operator can indeed, thanks to the invention, guarantee continuity of service to users while ensuring the effectiveness of the mitigation actions implemented to respond to suspicious behavior detected in the network.These mitigation actions consist, for example, of quarantining an IP address associated with suspicious behavior, such quarantine being able to consist of isolating incoming traffic to this IP address, and / or rejecting connections sent with this address, and / or redirecting traffic characteristic of connections sent with this address to a traffic inspection module, and / or removing this IP address from the pool of IP addresses that can be used to process packets from a client device, etc.

[0018] Thus, as appears from the above, the invention is based on the first device triggering an action in response to suspicious behavior associated with a shared IP address, but also, when this action includes a request for delegation of IP addresses, on the second device collaborating with the first device by responding favorably to its request.

[0019] The invention therefore also relates, according to another aspect, to a method of collaboration with a first device located in a network and managing a first set of IP addresses comprising an IP address associated with suspicious behavior, said method being intended to be implemented by a second device managing a second set of IP addresses and comprising: a step of receiving, from the first device, a request to delegate at least one IP address from the second set to the first device so that the first device can select said at least one delegated IP address to process at least one data packet from at least one client device served by the first device; and a step of sending to the first device a list comprising at least one IP address from the second set delegated by said second device to the first device.

[0020] Correlatively, the invention also relates to a device, called a second device, located in a network, said second device managing a second set of IP addresses and comprising: a reception module, configured to receive, from a first dis- positive managing a first set of IP addresses comprising an IP address associated with suspicious behavior, a request to delegate at least one IP address from the second set to the first device so that the first device can select said at least one delegated IP address to process at least one data packet from at least one client device served by the first device; and a sending module, configured to send to the first device, a list comprising at least one IP address from the second set delegated by said second device to the first device.

[0021] The advantages of the collaboration method and the second device are similar to those described previously for the management method and the first device.

[0022] The suspicious behaviors associated with IP addresses that can trigger the execution of an adjustment of an IP address sharing rate or a delegation request in accordance with the invention can be of different natures; for example, the suspicious behavior detected can result from the IP address belonging to a blocked list (or "block-list" in English), or the fact that it is associated with a low reputation level, etc. These suspicious behaviors can be detected directly (i.e. locally) by the first device, or by other entities, then responsible for notifying the first device.

[0023] Thus, in a particular embodiment, the detection step may comprise the reception of a notification issued by an attack detection function (embedded for example in an attack mitigation system or center also referred to as AMS for “Attack Mitigation System” in English) or of a notification issued by an IP address reputation system.

[0024] Such a notification may be issued for example via a DOTS (for “DDoS Open Threat Signaling”) channel established between the first device and the aforementioned attack detection function or IP address reputation system. In a manner known per se, DOTS is a client / server architecture, specified by the IETF, which aims to provide a signaling mechanism for detecting suspicious traffic or even confirmed attacks so as to implement appropriate mitigation actions as quickly as possible. Thus, the implementation of the invention may rely in particular on the implementation by the first device of the mechanism described in the IETF document RFC 9244 entitled “Distributed Denial-of-Service Open Threat Signaling (DOTS) Telemetry”, June 2022, to receive notifications concerning attacks of which an IP address belonging to the first set is the target.For attacks whose source is an IP address from the first set, one can consider specifying an extension of this DOTS signaling mechanism consisting of defining a new "Uri-Query" option called for example "source-address", valued with the IP address in question, as detailed further later.

[0025] Of course, this is only an illustrative example of implementation of the invention, and other notification mechanisms of the first device can be envisaged.

[0026] As mentioned above, the invention applies in different contexts.

[0027] Thus, in a particular embodiment, it can be envisaged that the first device is configured with a list of second devices according to the invention with which it can envisage collaborating and more particularly, to which it can send a request for delegation of IP addresses.

[0028] In another embodiment, the management method may comprise a step of discovery of said at least one second device.

[0029] Such dynamic discovery of devices likely to delegate IP addresses to it can be implemented by the first device, for example, by using a dynamic routing protocol such as OSPF (for “Open Shortest Path First”), or by querying a network function such as NRF (for “Network Repository Function”) in a 5G network.

[0030] In a particular embodiment, the management method may further comprise a step of establishing with said at least one second device at least one communication channel, for example an encrypted communication channel. This communication channel may be established so as to be used unidirectionally by the first device to send a delegation request to the second device, or bidirectionally, each of the first and second devices being able to use this channel indifferently to send a delegation request.

[0031] The communication channel established between the first device and a said second device may in particular be an encrypted communication channel based for example on the QUIC protocol, and possibly, if applicable, on the definition of a new transport parameter allowing the first device and the second device to inform themselves about their respective support for the mechanism proposed by the invention (and in particular the delegation of IP addresses).

[0032] The QUIC protocol advantageously makes it possible to establish an encrypted and therefore secure communication channel between the two devices; in accordance with the QUIC protocol, not only the useful data exchanged by the first and second devices are encrypted, but also most of the control data, which provides additional protection against possible attacks. However, this is a simple example of implementation of the invention, and other mechanisms can be envisaged. For example, the communication channel can rely on a GRE (for "Generic Routing Encapsulation") or IPsec (for "IP security") tunnel, or rely on the IP-in-IP protocol. It should be noted that establishing an encrypted communication channel advantageously makes it possible to strengthen the security of the proposed mechanism, particularly if a device (or node) of the network is compromised.However, it is possible to do without such encryption if we consider that all devices on the network are trusted.

[0033] The discovery step and / or the step of establishing a communication channel with a second device may be implemented before or after the detection step. In other words, these steps may be triggered by the detection of suspicious behavior associated with an IP address, so as to reduce in particular the resources monopolized for the implementation of the invention, or be carried out beforehand, independently of any detection of suspicious behavior associated with an IP address managed by the first device, so as to reduce the reaction time of the first device to suspicious behavior associated with an IP address that it manages.

[0034] Establishing a communication channel between the first device and a second device allows the devices to exchange various information, useful for their collaboration.

[0035] Thus, in a particular embodiment, the delegation request addressed by the first device may include a number and / or type of delegated IP addresses desired by the first device.

[0036] In another embodiment, the management method further comprises a step of reception by the first device, in response to a said delegation request addressed by the first device to a said second device, at least one element from among: a list comprising at least one IP address delegated by this second device to the first device; a duration during which said list is delegated to the first device; information representative of a maximum volume of traffic, associated with the use of an IP address delegated by said at least one second device to the first device and which can be managed by the second device.

[0037] This information can make collaboration between the two devices more efficient and better adapted to the needs of the first device and / or the capabilities of the second device. It is not limiting in itself, and other information can be exchanged between the devices.

[0038] The information representing the maximum volume of traffic transmitted by the second device can be used by the first device to optimally use the IP addresses delegated to it and best distribute the traffic passing through it.

[0039] For example, in a particular embodiment, the management method comprises a step of selecting at least two IP addresses delegated by said second distinct devices to process packets from at least two distinct client devices served by the first device.

[0040] Thus, in this embodiment, the first device can distribute all or part of the traffic passing through it and attached to separate client equipment between several IP addresses delegated by said separate second devices. This embodiment has a preferred application when, for example, one of said second devices is not able to process all of the traffic in question. The first device can then call on other devices to process the excess traffic compared to the maximum traffic volume indicated by said second device with insufficient capacity.

[0041] In a particular embodiment, the management method further comprises: a step of receiving, from an internal source IP address, a first data packet comprising data intended for a recipient entity; a step of replacing this internal source IP address with a said IP address delegated by a said second device to the first device and selected by the first device to process the first data packet; and a step of transmitting the data with the IP address delegated to said second device, via a communication channel established with it, so that said data is routed to the recipient entity.

[0042] Similarly, in a particular embodiment, the management method may further comprise: a step of receiving, via a communication channel with a said second device, a second data packet sent by a sending entity and comprising data intended for an IP address of the second set of IP addresses managed by the second device; and if said IP address is delegated to the first device by the second device and selected by the first device to process data packets from a client equipment served by the first device, a step of transmitting said data to an internal IP address allocated to said client equipment.

[0043] Correlatively, in a particular embodiment, the collaboration method further comprises: a step of receiving, via a communication channel established with the first device, a first data packet comprising data intended for a recipient entity and sent with a source IP address belonging to the second set of IP addresses managed by the second device; and if said source IP address is a said IP address delegated by the second device to the first device, a step of transmitting said data to the recipient entity without modifying said source IP address of said data.

[0044] Furthermore, in another embodiment, the collaboration method may also comprise: a step of receiving a second data packet comprising data sent by a sending entity and intended for a destination IP address belonging to the second set of IP addresses managed by the second device; and if said IP address is a said IP address delegated by the second device to the first device, a step of transmitting said data to the first device via the communication channel established with said first device without modifying said destination IP address of said data.

[0045] These embodiments of the management method and the collaboration method have a preferred application when the first and second devices in question are operator NATs. In these embodiments, the data packets sent by or to the client equipment (referred to as client equipment data packets) to which the first device assigns an IP address delegated by a said second device transit via a communication channel (possibly secure) established between the first and second devices. It should be noted that when the data packets associated with an IP address delegated by the second device to the first device reach the second device, the latter does not make any modification to the delegated IP address in question (no address translation), since it is an address belonging to the address pool that it manages.In other words, it disables the address translation function that it usually applies to packets that pass through it.

[0046] Advantageously, these embodiments do not require modification of the routing policies implemented in the network, nor of the routing policies for traffic passing through the first and second devices. Indeed, these embodiments do not require synchronization of the routing tables of the network equipment linked to the delegation of IP addresses, and consequently, make it possible to overcome the impact of convergence times associated with the synchronization of the routing tables maintained by the network equipment. The implementation of the invention therefore does not impact the stability of the routes installed in the network. Once the delegation of IP addresses has been accepted by the second device, the delegated IP addresses can be used without delay by the first device to process the packets sent by or to the client equipment that reach it.

[0047] In another embodiment, it is possible to envisage modifying the routing tables to ensure that the data packets associated with an IP address delegated by a said second device to the first device are directly routed to the first device without passing through the second device. In this other embodiment, the communication channels established where appropriate between the first and second device(s) are only used for control purposes (e.g. for an address delegation request) or for data routing for the time required for routing convergence.

[0048] In a particular embodiment, the management and collaboration methods are implemented by a computer.

[0049] The invention also relates to a computer program on a recording medium, this program being capable of being implemented in a computer or more generally in a first device in accordance with the invention and comprising instructions adapted to the implementation of a management method as described above.

[0050] The invention also relates to a computer program on a recording medium, this program being capable of being implemented in a computer or more generally in a second device in accordance with the invention and comprising instructions adapted to the implementation of a collaboration method as described above.

[0051] Each of these programs may use any programming language, and may 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 other desirable form.

[0052] The invention also relates to an information medium or a recording medium readable by a computer, and comprising instructions of a computer program as mentioned above.

[0053] The information or recording medium may be any entity or device capable of storing programs. For example, the medium may include a storage medium, such as a ROM, for example a CD ROM or a microelectronic circuit ROM, or a magnetic recording medium, for example a hard disk, or a flash memory.

[0054] On the other hand, the information or recording medium may be a transmissible medium such as an electrical or optical signal, which may be conveyed via an electrical or optical cable, by radio link, by wireless optical link or by other means.

[0055] The program according to the invention can in particular be downloaded from an Internet-type network.

[0056] Alternatively, the information or recording medium may be an integrated circuit in which a program is incorporated, the circuit being adapted to execute or to be used in the execution of the management and collaboration methods according to the invention.

[0057] According to yet another aspect, the invention also relates to a system at least one first device according to the invention and at least one second device according to the invention, configured to process at least one request for delegation of IP addresses received from a said first device.

[0058] The system benefits from the same advantages mentioned above as the first and second devices.

[0059] It is also possible to envisage, in other embodiments, that the management and collaboration methods, the first and second devices and the system according to the invention present in combination all or part of the aforementioned characteristics. Brief description of the drawings

[0060] Other characteristics and advantages of the present invention will emerge from the description given below, with reference to the appended drawings which illustrate an exemplary embodiment thereof without any limiting character. In the figures: [Fig. 1] Figure 1, already described, represents address translations carried out by network access equipment incorporating a NAT function and an operator NAT (CGN) deployed in the network; [Fig. 2] Figure 2 represents a system according to the invention in its environment, in a particular embodiment; [Fig. 3] Figure 3 represents an example of hardware architecture of a computer hosting a first device and / or a second device of the system of Figure 2; [Fig. 4] Figure 4 represents the functional modules of a first device and a second device of the system of Figure 2, in accordance with the invention, in a particular embodiment; [Fig. 5] Figure 5 represents the main steps of a management method according to the invention as implemented by a first device of the system of Figure 2; [Fig. 6] Figure 6 represents the main steps implemented by the first device of Figure 2, when in response to suspicious behavior associated with an IP address that it manages, it executes an action consisting of sending a request for delegation of at least one IP address to a second device of the system of Figure 2; [Fig. 7] Figure 7 represents the main steps implemented by a second device of the system of Figure 2, requested by the first device of said system to delegate IP addresses to it; [Fig. 8] Figure 8 represents, by an illustrative example, the processing carried out in the context of the invention by the first and second devices of the system of Figure 2 on messages from client equipment served by the first device; [Fig. 9] Figure 9 represents an example of a system according to the invention serving a CPE type customer equipment; [Fig. 10] Figure 10 illustrates a network comprising several levels of operator NAT, each level of operator NAT including a system according to the invention. Description of embodiments of the invention

[0061] Figure 2 represents, in its environment, a system 1 according to the invention, in a particular embodiment in which it is located in a communications network 2 managed by an operator OP2. No assumption is made as to the nature of the network 2, which can be fixed or mobile.

[0062] Network 2 comprises a plurality of operator NATs or CGNs (or equivalently, a plurality of operator NAT or CGN instances), deployed on separate equipment, and referenced CGN#1, CGN#2,..., CGN#M, where M denotes an integer greater than 1. Each operator NAT CGN#n, n = 1,...,M has at least one external IP address (for example public) noted @IP-CGN#n which has been allocated to it by operator OP2.

[0063] In the embodiment described here, it is assumed that network 2 is configured to use the IPv4 protocol and that each operator NAT CGN#n, n=l,...,M is of type NAT44, as described in the document RFC 3032 published by the IETF and entitled "Traditional IP Network Address Translator (Traditional NAT)", January 2001. Each operator NAT CGN#n, n=l,...,M, is configured with a set (or pool) of external IPv4 addresses (for example public) dedicated and distinct, noted POOL#n, which it manages and can use to process the data packets it receives, these packets including data sent by or intended for client equipment of the network 2.

[0064] The IPv4 addresses of a set of addresses POOL#n may be contiguous (e.g. 1.2.3.0 / 24) or not (e.g. 1.2.3.4 / 32 and 11.25.25.36 / 32). It is assumed that routes are advertised in and out of network 2 so that traffic destined for an IP address of a set POOL#n is received by the operator NAT CGN#n to which this set of addresses is assigned. For the sake of simplification, it is assumed, in the embodiment described here, that network 2 implements a single level of operator NAT, i.e. that the packets from the client equipment of network 2 are processed, in the sense of address translation, by only one operator NAT among the operator NATs CG N# n, n= l,...,M.

[0065] The IPv4 addresses of each POOL#n set assigned to a CGN#n operator NAT may be, in the embodiment described here, shared between several client devices served by the CGN#n operator NAT. By “client device served by an operator NAT” (or equivalently here, “client device attached to or managed by an operator NAT”), it is meant that the operator NAT is responsible for processing the data packets of this client device (i.e., containing data sent or intended for this client device), and in particular for the translation of the IP addresses carried in these packets, i.e., the translation of a so-called “internal” address into a so-called “external” address (or vice versa depending on the direction of communication considered).

[0066] It should be noted that a client device does not necessarily have knowledge of the designated operator NAT to serve it. Similarly, the CGN#n operator NAT does not necessarily have explicit knowledge of the client device to which a packet it must process relates and which is transported using an internal IP address (the information concerning the client device can however be known if a mechanism such as described for example in the document RFC 7785, entitled "Recommendations for Prefix Binding in the Context of Softwire Dual-Stack Lite", February 2016, is implemented by the operator NAT). It uses the "internal" IP address used to transport this packet to it to translate it into an "external" IP address of the POOL#n set.Regardless of the operating mode of the CGN#n operator NAT, the fact remains that the CGN#n operator NAT can select, to process packets from several separate client devices, the same external IPv4 address from among the external IPv4 addresses of the POOL#n set that it manages.

[0067] In the remainder of the description, for the sake of simplification, the notions of "internal / external address" are sometimes omitted to describe the IP addresses considered, unless it is necessary to distinguish these addresses. Indeed, these notions are relative and defined in relation to the operator NAT considered: at the level of a given operator NAT, an internal IP address carried by a packet sent by a client device is translated into an external IP address (and vice versa, depending on the direction of communication considered). However, when two levels of operator NAT are considered, an operator NAT of the first level translates an internal address as it appears in the header of a packet sent by a client device into an external address, but this external address is considered as an internal address from the point of view of an operator NAT of the second level.

[0068] No assumption is made as to the nature of the client equipment to which the invention applies. These may be terminals (for example smartphones, tablets, computers), access equipment from a LAN (for "Local Area Network" in English) to the network 2 (for example CPEs to which terminals are connected), etc. By way of illustration, in the embodiment illustrated by Figure 2, the client equipment served by the operator NATs CGN#n, n = l,...,M are terminals.

[0069] The criteria for selecting and using an IP address (then called "active") from a POOL#n set are specific to each operator NAT; each operator NAT decides locally (typically in accordance with its configuration) how the active IP addresses from the set assigned to it are managed. For example, an operator NAT CGN#n, n = l,...,M, can decide the number of IP addresses to use from among those in the POOL#n address set that it manages depending on the sharing rate(s) with which it has been configured, if applicable, and the number of active client devices (i.e. having an active connection, represented in a database or BIB table maintained by the operator NAT CGN#n, as mentioned previously) that it serves.The same sharing rate (noted here "l:x" to indicate that the same IP address can be shared between x client devices, or more generally that the same external IP address can be shared between x internal IP addresses given the previous remark) can be applied by the CGN#n operator NAT to each (external) IP address intended to be shared. Alternatively, it is possible to consider applying different sharing rates depending on the IP addresses or according to other criteria (for example geographical considerations). It is also possible to consider sharing only certain IP addresses, etc.

[0070] The criteria for attaching a group of customer equipment to a given CGN#n operator NAT are known to those skilled in the art and are not detailed here; they fall within the know-how of the operator of the CGN#n, n=1,...,M operator NATs, namely here the OP2 operator of network 2. The same applies to the way in which the CGN#n, n=1,...,M operator NATs are placed on the paths taken by the communications established by the customer equipment they serve.

[0071] The hypotheses mentioned above are not limiting in themselves. The invention can also be applied in other contexts, and in particular to IPv6 addresses, to other types of operator NAT (for example NAT64, DS-Lite, NPTv6), the operator NATs of the network 2 can all be of the same type or of different types, co-located or deployed on separate hardware equipment, or even virtualized and hosted in cloud-type infrastructures. In addition, the operator NATs can be deployed in a distributed manner in the network 2 (with (instances of) operator NAT deployed as close as possible to the customer equipment) or in a centralized manner. It is also possible to envisage several levels of operator NAT, that is to say that a packet from a customer equipment of the network 2 can be the subject of successive address translations carried out by operator NATs deployed on several levels within the network 2.

[0072] For the sake of simplification here, it is assumed that all the CGN#n, n= l,...,M operator NATs deployed in the network 2 belong to the system 1, and that each CGN#n, n= l,...,M operator NAT embeds various modules configured to implement, depending on the context in which the CGN#n operator NAT is located, a management method or a collaboration method according to the invention. In other words, each CGN#n, n= l,...,M operator NAT embeds the functional modules of a first DI device according to the invention, capable of detecting suspicious behavior associated with a IP address that it manages, and the functional modules of a second device D2 according to the invention, capable of collaborating with another operator NAT of the system 1 (in Figure 2, for the sake of simplification, the devices DI and D2 have only been represented for the operator NAT CGN#1); depending on the context, the operator NAT CGN#n activates the functional modules of one or other of the devices DI and D2 that it embeds. In the embodiment described here, the same operator NAT CGN#n of the system 1 can therefore sometimes be a first device according to the invention, sometimes a second device according to the invention.

[0073] Of course, this hypothesis is not limiting in itself and other configurations for the system 1 can be envisaged. For example, the system 1 can integrate only a subset of the operator NATs of the network 2, and the operator NATs concerned can embed only the functional modules of a first device DI according to the invention or only the functional modules of a second device D2 according to the invention, it being understood that among the operator NATs of the system 1, there are at least one first device DI and at least one second device D2 conforming to the invention.

[0074] Furthermore, each operator NAT CGN#n, n=1,...,M, of the system 1 has a communication channel (for example here a DOTS channel) established with at least one attack detection function (or system), known per se and not described in detail here. The operator NAT CGN#n, n=1,...,M of the system 1 can request one or more distinct attack detection functions via the DOTS channels thus established. In the example of Figure 2, we are interested in DDoS type attacks, and the attack detection function(s) with which the operator NAT CGN#n, n=1,...,M, establish DOTS channels are DDoS or DMS mitigation centers. Of course, the invention applies to other types of computer attacks and to other attack detection functions / systems (for example more generally to AMS centers).

[0075] Each DOTS channel thus established allows each NAT operator CGN#n, n = l,...,M, to receive from DMS centers information concerning DDoS attacks whose source or destination is an address in the POOL#n set of IP addresses that it manages. More specifically: to receive via such a DOTS channel notifications from a DMS center concerning attacks whose target is an IP address in the POOL#n set, the NAT operator CGN#n is configured to use here a subscription mechanism with the DMS center such as that described in the RFC 9244 document cited above, in particular in point 8.1.1; to receive via such a DOTS channel notifications from a DMS center concerning attacks whose source is an IP address in the POOL#n set, a new extension to the mechanism described in the RFC 9244 document can be specified.The proposed new extension consists of defining a new "Uri-Query" option, called for example "source-address", allowing the NAT operator CGN#n to indicate in a query addressed to the DMS center, the addresses of the POOL#n set for which it wishes to be notified. Table 1 illustrates an example of such a query including the new "source-address" option filled in with the IP address "1.2.3.4".

[0076] [Table 1]

[0077] Notifications sent by a DMS center to the NAT operator CGN#n can be generated by the DMS center following local detection or following receipt by the DMS center of a notification from other entities (for example from another DMS center).

[0078] In the embodiment described here, a DOTS channel is also established between each operator NAT CGN#n, n=1,...,M of the system 1 and a reputation system REP_SYS. This DOTS channel is established for example here using a configuration request characteristic of the RESTCONF protocol. This request includes a subscription filter conditioning the notifications sent by the reputation system REP_SYS to the operator NAT CGN#n. The subscription filter designates for example all or part of the IP addresses of the set POOL#n managed by the operator NAT CGN#n.

[0079] As is known, such a REP_SYS reputation system is adapted to evaluate a reputation level of an IP address, this reputation level reflecting the degree of trust that can be placed in this IP address. It is established by collecting specific data from different entities (for example a network router), such as the volume of suspicious traffic associated with the IP address, its possible membership in a blocked list or "block-list", its possible involvement in computer attacks, etc. The higher the reputation level of an IP address, the more its behavior is considered secure. Conversely, a low reputation level (typically below a certain threshold) reflects a high risk of malicious behavior associated with the use of the IP address (and therefore of the traffic sent with such an address as the source address).The DOTS channel established between a CGN#n operator NAT and the REP_SYS reputation system thus allows the CGN#n operator NAT to obtain the reputation levels determined by the REP_SYS reputation system for the IP addresses in the POOL#n set that the CGN#n operator NAT manages.

[0080] It should be noted that the DMS centers and the reputation system can be operated by the same administrative entity (for example by the OP2 operator managing the NAT operator CGN#n, n= l,...,M) or by separate administrative entities. Furthermore, no assumption is made regarding the location of these systems. In particular, the same hardware equipment can carry the REP_SYS reputation system and a DMS center.

[0081] In the embodiment described here, the operator NATs CGN#n, n=l,...,M are hosted by equipment having the hardware architecture of a computer 3 as shown in Figure 3.

[0082] Each computer 3 comprises a processor PROC, a random access memory MEM, a read only memory ROM, a non-volatile memory NVM, and means of communication COM, allowing the operator NATs CGN#n, n = l,...,M, to communicate in particular with other entities of the network 2 (and more particularly to communicate with each other), with the DMS centers and the reputation system REP_SYS, as well as with the client equipment that they serve. Such means of communication are known per se and are not described in detail here.

[0083] The non-volatile memory NVM of the computer 3 constitutes a recording medium in accordance with the invention, readable by the processor PROC and on which computer programs PROG1 and PROG2 in accordance with the invention are recorded here.

[0084] More specifically, the computer program PROG1 comprises instructions defining the main steps of a management method according to the invention. It defines functional modules of a first DI device according to the invention, and incidentally, in the embodiment described here, of each operator NAT CGN#n, n=1,...,M. These functional modules rely on or control the PROC, MEM, ROM, NVM, and COM elements of the computer 3 cited above, and comprise here, for each operator NAT CGN#n, as illustrated by FIG. 4: a detection module 4, configured to detect suspicious behavior associated with an active IP address of the set POOL#n managed by the operator NAT CGN#n, selected by the latter to process at least one packet from a client device served by the operator NAT CGN#n; and an execution module 5, configured to execute at least one action in response to the suspicious behavior detected by the detection module 4.More particularly, in the embodiment described here, the execution module EXEC is configured to choose the action(s) to be executed from a given set ACT of actions, comprising at least the following actions: o an action ACT1 consisting of removing the IP address associated with a suspicious behavior from the set POOL#n of IP addresses that can be selected by the operator NAT CGN#n to process the packets of the client equipments that it serves (this removal can concern only the connections that may be established in the future by a client equipment, but also the current connections (in other words active, as represented in the BIB table maintained by CGN#n)); o an action ACT2 consisting of adjusting at least one sharing rate of at least one IP address from the set POOL#n; and o an action ACT3 consisting of requesting a delegation of IP addresses to at least one other operator NAT CGN#j of the system 1, with j*n.By delegation, we mean here that the NAT operator CGN#j agrees to allocate one or more IP addresses from its POOL#j set to the NAT operator CGN#n so that the latter can use it or them to process packets from client equipment attached to it. The choice of the action or actions executed by the execution module 5 may depend on the context (for example the nature of the malicious behavior detected, the number of active connections processed by the NAT operator CGN#n, the effective sharing rate of the IP addresses of the set POOL#n that it manages, the severity of the attack, etc.). In the embodiment described here, the module 5 is configured to choose, in response to suspicious behavior associated with an IP address, at least one action from the action ACT2 of adjusting at least one sharing rate and the action ACT3 of requesting delegation. Of course, other actions may be selected by the module 5 in addition to one of these two actions, and other actions may be considered in the set ACT taken into account by the execution module 5.

[0085] The PROG1 program also defines here three other modules of the NAT operator CGN#n as the first DI device according to the invention, namely: a discovery module 6, configured to discover the operator NATs of the system 1 likely to collaborate with the operator NAT CGN#n and in particular to delegate IP addresses to it; an establishment module 7, configured to establish communication channels with all or part of the operator NATs thus discovered; and a data transmission / reception module 8. This module 8 is in particular configured to transmit and / or receive data via the communication channels established by the establishment module 7 and to transmit and / or receive data packets from the client equipment served by the operator NAT CGN#n.

[0086] Modules 4 to 8 are described in more detail later with reference to the steps of the management method according to the invention.

[0087] The computer program PROG2 stored in the non-volatile memory NVM of the computer 3 comprises instructions defining the main steps of a collaboration method according to the invention. It defines functional modules of a second device D2 according to the invention, and incidentally, in the embodiment described here, of each NAT operator CGN#n, n = l,...,M.These functional modules rely on or control the PROC, MEM, ROM, NVM, and COM elements of the computer 3 mentioned above, and comprise here, for each NAT operator CGN#n, as illustrated in Figure 4: a receiving module 9, configured to receive from another NAT operator CGN#k of the system 1, with k¥=n, a request for delegation of at least one IP address from the set POOL#n of IP addresses managed by the NAT operator CGN#n; and a sending module 10, configured to send to the NAT operator CGN#k, a list comprising at least one IP address from the set POOL#n that the NAT operator CGN#n agrees to delegate to it.

[0088] The PROG2 program also defines a data transmission / reception module 11 here.

[0089] Modules 9 to 11 of the CGN#n operator NAT are described in more detail later with reference to the steps of the collaboration method according to the invention.

[0090] It should be noted that in addition to modules 4 to 11 just mentioned, each CGN#n operator NAT also has a module 12 for managing the POOL#n set of IP addresses assigned to it and a module 13 for address translation. Of course, functions other than address translation can be implemented by the CGN#n operator NAT (for example an ALG function, etc.), however these functions are not considered here for the sake of simplification.

[0091] The management module 12 is in particular responsible for selecting a so-called external IP address from the set POOL#n (possibly supplemented by the IP addresses which are delegated to it where appropriate) to process each packet from a client device that it receives carrying a so-called internal IP address, and to respect the IP address sharing rate(s) with which it has been configured. The external IP address selected to process a packet from a client device is stored by the management module 12 in association with the internal IP address, in the BIB table maintained by the operator NAT CGN#n, and stored here in the non-volatile memory NVM of the operator NAT CGN#n. As mentioned previously, the management module 12 can associate the same external IP address from the set POOL#n with several distinct internal IP addresses, in accordance with a sharing rate with which it has been configured where applicable previously.

[0092] The address translation module 13 is configured to process the packets from client equipment received by the operator NAT CGN#n, and to translate, if necessary, the IP addresses of these packets in accordance with the information stored in the BIB table. The structure of the BIB table, its supply and maintenance, as well as the processing of packets from client equipment served by the operator NAT CGN#n in accordance with the information recorded in the BIB table are known per se and are not repeated further here.

[0093] When the same external IP address is shared between several client devices, several entries in the BIB table associate this external IP address with several distinct internal IP addresses. In order to allow the translation module 13 to associate the correct internal IP address with a data packet that it receives, different techniques can be envisaged in a manner known per se. For example, the differentiation can be done on the basis of a state maintained by the operator NAT CGN#n in a local table (a port number associated with the internal IP address in the BIB table, an identifier of the client device, a transport protocol, etc.), or by implementing an algorithm provided for this purpose (for example for an operator NAT of type NPTv6), etc.

[0094] We will now describe, with reference to Figure 5, the main steps of a management method according to the invention as they are implemented by each NAT operator CGN#n of the system 1 when it acts as the first DI device according to the invention, that is to say when it detects malicious behavior associated with an IP address that it manages.

[0095] In the embodiment described here, each operator NAT CGN#n, n = l,...,M of the system 1 first proceeds to discover, via its discovery module 6, the other operator NAT CGN#j, with j=l,...,M and j*n, of the system 1 (step E10). For this purpose, the discovery module 6 can use a dynamic routing protocol such as the OSPF protocol, or in the context of a 5G type network 2, query the NRF function of the network 2, etc.

[0096] Then, each operator NAT CGN#n, n=1,..,M of the system 1 establishes, via its establishment module 7, a communication channel with each of the operator NATs discovered during the discovery step E10 (step E20). These communication channels are called in the remainder of the description COGITARE channels (for “Collaborative cGns for advanced Ip network repuTAtion safeguaRd / softEnings” in English). They can be established so as to be used unidirectionally (only the operator NAT at the origin of the establishment of the channel can use the channel to send a delegation request as described later) or bidirectionally (each operator NAT at one end of the channel can send a delegation request to the other operator NAT).

[0097] In the embodiment described here, these COGITARE channels are encrypted and are based on the QUIC protocol, described in particular in the IETF RFC 9000 document entitled "QUIC: A UDP-Based Multiplexed and Secure Transport", May 2021. Alternatively, the COGITARE channels may be based on a protocol other than QUIC, for example on the IP-in-IP protocol allowing IP packets to be encapsulated in other IP packets by establishing tunnels (or "tunneling" in English). These channels may not be encrypted, if the operator NATs are considered as trusted entities, for example.

[0098] To implement the invention in the context of the QUIC protocol, a new transport parameter is defined, called for example "delegate_resources_enable". This parameter is valued here at 1 by an operator NAT when it is configured to implement a collaboration method according to the invention, that is to say it is able to delegate IP addresses from the pool of addresses that it manages to another operator NAT of the system 1. It is noted that this ability does not presume the actual availability of IP addresses to be delegated at the level of the operator NAT in question, but only its capacity, in the event that such IP addresses would be available in the pool of addresses that it manages, to delegate such IP addresses, that is to say its capacity to implement the collaboration method according to the invention and to act as a second device according to the invention.Thus, it is assumed here that when a NAT operator CGN#n initializes the establishment of a COGITARE channel with another NAT operator CGN#j, j*n, it inserts into the QUIC frame that it sends the parameter “delegate_resources_enable” valued at 1. It should be noted that this parameter can be used additionally by a NAT operator to signal to another NAT operator that in addition to being configured to implement a collaboration method according to the invention, it is also configured to implement a management method according to the invention, that is to say that it may be required to request the other NAT operator to delegate IP addresses to it.This additional information may be transmitted for informational purposes, and may be used by the other NAT operator to carry out a check if necessary if it receives a delegation request from this NAT operator (for example to determine whether this delegation request is consistent with what the NAT operator had announced to it).

[0099] If the NAT operator CGN#j with which the NAT operator CGN#n is attempting to establish a COGITARE channel is not able to collaborate with another NAT operator of system 1 and delegate at least one IP address to it, it responds with a QUIC frame in which the "delegate_resources_enable" parameter is set to 0, or with a QUIC frame not containing this parameter. In this case, the procedure for establishing a COGITARE channel is prematurely closed, and no COGITARE channel is established.

[0100] Conversely, if the NAT operator CGN#j with which the NAT operator CGN#n attempts to establish a COGITARE channel is able to delegate one or more of the IP addresses it manages, it responds with a QUIC frame in which the “delegate_resources_enable” parameter is set to 1, and the COGITARE channel is established according to the principles defined by the QUIC protocol.

[0101] The NAT operator CGN#n stores here in a CAPA table stored in the non-volatile memory NVM, for each NAT operator CGN#j requested by the NAT operator CGN#n for the establishment of a COGITARE channel, its ability or not to delegate IP addresses. This amounts to storing in the CAPA table the value of the parameter "delegate_resources_enable" returned or deduced from the QUIC frame sent by the NAT operator CGN#j in response to the request to establish a COGITARE channel from the NAT operator CGN#n. The NAT operator CGN#n can also store in the CAPA table other information relating to each NAT operator CGN#j requested, such as for example one or more IP addresses allowing it to be reached.

[0102] Of course, the values ​​1 and 0 proposed to enhance the parameter "delegate_resources_enable" are given only for illustrative purposes and are not limiting in themselves, other values ​​can be considered to indicate whether or not a NAT operator is able to delegate IP addresses to another NAT operator. Furthermore, the parameter "delegate_ressources_enable", whatever its value, can be exchanged between operator NATs at any time (when attempting to establish the COGITARE channel as described previously, or later, once the channel is established).

[0103] We now assume that one of the operator NATs of system 1, for example the operator NAT CGN#1 for illustrative purposes, detects via its detection module 4 a suspicious behavior associated with an IP address of the set POOL#1 of IP addresses that it manages (answer yes to test step E30). By "suspicious behavior", we mean here that the behavior associated with the IP address in question, noted in the sequence bad@IP, is not normal and suggests that the IP address is used for malicious purposes (for example it is associated with suspicious activity) or targeted by an attack.

[0104] Detection of such suspicious behavior can be achieved by various means.

[0105] For example, the CGN#1 operator NAT detection module 4 can receive a notification from the REP_SYS reputation system indicating a reputation level of the bad@IP address below a determined threshold, with which CGN#1 was previously configured and below which the behavior associated with the use of the IP address is considered malicious or at least suspicious.

[0106] According to another example, the detection module 4 may receive a notification from an attack detection function of a DMS center (or more generally of an AMS center) indicating to it that the bad@IP address belongs to a blacklist of IP addresses considered to be associated with malicious actions or that the bad@IP address has been identified as a target or used as the origin of an attack.

[0107] It should be noted that in the notifications from the REP_SYS system or the DMS center, a domain name may be targeted, in which case the detection module 4 is configured to proceed with the resolution of this domain name in order to obtain the corresponding bad@IP address.

[0108] In yet another example, the detection module 4 may integrate an attack detection function and determine locally that the bad@IP address is associated with suspicious behavior.

[0109] These examples are given for illustrative purposes only and are not limiting of the invention.

[0110] Following this detection, CGN#1 verifies here that the bad@IP address belongs to the POOL#1 set of IP addresses assigned to it (which is the case here) (step E40). If necessary, it activates its execution module 5 to execute at least one action in response to this detection. Note that the verification step E40 is optional (if it is not implemented, the execution module 5 is activated upon detection by module 4 of the suspicious behavior associated with the bad@IP address). [YES] The action or actions then executed by the execution module 5 can be selected by it depending on the context. As mentioned previously, in the first embodiment described here, the execution module 5 chooses to execute at least one action from the set ACT of actions comprising: the action ACT1 consisting of removing the bad@IP address from the IP addresses of the set POOL#1 that can be selected by CGN#1 to process the packets of the client equipments that it serves (referred to more simply in the following as “active IP addresses”). It should be noted that this removal may concern only future connections likely to be established by client equipments (typically packets concerning other client equipments than those already served by CGN#1 at the time of removal), and / or also active connections (i.e. i.e. in progress). The choice of one or the other of the strategies may result from a policy of the operator OP2, differ depending on the context (for example the location of the source of the attack), etc. For example, maintaining the bad@IP address to process packets characteristic of active connections may be justified when the source of an attack is internal to network 2, and / or to avoid having to migrate all the client equipment served with the bad@IP address by CGN#1; the ACT2 action consisting of adjusting at least one sharing rate of at least one IP address of the set POOL#1; for example, at least one sharing rate may be increased if the operator NAT CGN#1 no longer has IP addresses to be able to serve the client equipment attached to it (for example to go from 1:10 to 1:20 or from 1:2 to 1:5).This dynamic adjustment of at least one sharing rate advantageously makes it possible to compensate for the malicious behavior associated with the bad@IP address, and in particular, its removal, if applicable, from the active IP addresses if the AGIT action is also executed. It is noted that such a dynamic adjustment can apply globally to the sharing rates of all the IP addresses of the pool POOL#1 (with the exception of the sharing rate of the bad@IP address, which can on the contrary be reduced or even unused in the event of removal), or be applied in a differentiated manner to only a portion of the IP addresses of the pool POOL#1. In addition, a sharing rate can be adjusted several times if necessary (for example if several notifications reporting the suspicious behavior of several distinct IP addresses are received by the detection module 4); and the action ACT3 consisting of a request for delegation of IP addresses addressed to at least one other NAT operator CGN#j of the system 1, with j* l.The ACT3 action can notably be selected by the execution module 5 when the sharing rates of the active IP addresses of the POOL#1 set (distinct from the bad@IP address associated with suspicious behavior) have reached a maximum value, defined for example by the operator OP2, making it impossible to select the ACT2 action. This is however only an illustrative example, and the ACT3 action can be selected by the execution module 5 in other contexts.

[0112] In the embodiment described here, the execution module 5 is configured to choose, in response to the suspicious behavior of the bad@IP address, at least one of the actions ACT2 or ACT3, then to execute the action(s) thus chosen (step E50). It can also, in addition to the action ACT2 and / or ACT3, also execute the action AGIT. Of course, the invention is not limited to the aforementioned actions and other actions can be envisaged and executed as a variant by the NAT operator CGN#1 such as, for example, updating a set of the reputation system REP_SYS, marking the packets using the bad@IP address to facilitate the recognition and classification of the traffic so that traffic sinks can be dynamically set up in the network 2, etc.

[0113] Furthermore, it should be noted that the action(s) selected by the execution module 5 may be executed by the latter for a limited period of time. For example, the execution module 5 may, in accordance with the action ACT1, remove the bad@IP address from the list of IP addresses that may be selected to process messages from the client equipment that it serves for a given duration designated here by PAUSE_TIMER. If, at the end of the PAUSE_TIMER duration, the detection module 4 no longer detects any suspicious behavior associated with the bad@IP address (for example, it no longer detects any suspicious behavior associated with the bad@IP address) receives no new notifications from a DMS system or a REP_SYS system relating to this IP address), in this case it can reactivate the bad@IP address, in other words reintegrate it among the IP addresses of the POOL#1 set which can be selected to process messages arriving at CGN#1.

[0114] We will now describe in more detail, with reference to Figures 6 and 7, the progress of step E50 when the action ACT3 (request for delegation of IP addresses to another operator NAT) is selected by the execution module 5. Figure 6 illustrates the steps implemented by the operator NAT CGN#1 at the origin of the delegation request, while Figure 7 illustrates the steps implemented by an operator NAT of the system 1 receiving and accepting this delegation request (i.e. acting as a second device within the meaning of the invention). The steps illustrated by Figure 7 correspond to those of a collaboration method according to the invention. It goes without saying that although they are described on the basis of an illustrative example, the steps represented in Figures 5 to 7 apply to all the operator NATs of the system 1 depending on the role played by each of them (first or second device according to the invention).

[0115] In the embodiment envisaged here, as described previously, COGITARE channels have been established, previously during step E20, by CGN#1 with the operator NATs of system 1 discovered during step E10. Furthermore, during the establishment of these COGITARE channels, CGN#1 has been informed by the operator NATs with which it has established these channels, of their ability or not to delegate IP addresses to other operator NATs of system 1. This information is stored in the CAPA table of CGN#1. Thus, following the selection of the action ACT3, the CGN#1 execution module 5 consults the CAPA table and determines to which operator NAT(s) of the system 1 it can address its request for delegation of IP addresses (these are the operator NATs capable of implementing the invention and therefore capable of delegating IP addresses, in other words in the example considered here, those having indicated a “delegate_resources_enable” parameter valued at 1) (step E50-1).

[0116] It is noted that as a variant the discovery steps E10 and establishment E20 of the COGITARE channels can be implemented by the NAT operator CGN#1 after the step E30 of detecting suspicious behavior associated with the bad@IP address, for example after the execution module 5 has decided to execute the action ACT3.

[0117] The execution module 5 of CGN#1 requests at least one of the operator NATs identified during step E50-1 to delegate to it at least one IP address from the set POOL of IP addresses that it manages (step E50-2). It is noted that the execution module 5 can address this delegation request to all the operator NATs identified during step E50-1 or only to some of them (it can for example choose one randomly, or according to a determined criterion, etc.). For the sake of simplification, it is assumed here that CGN#1 addresses its delegation request to a single operator NAT of the system 1, namely to the operator NAT CGN#2 (second device within the meaning of the invention).

[0118] In the embodiment envisaged here of COGITARE channels based on the QUIC protocol, the CGN#1 execution module 5 requests a delegation of IP addresses to CGN#2 by sending it a QUIC frame, specified for the purposes of the invention and called for example here IP_RESOURCE_DELEGATE. This frame is sent by CGN#1 to CGN#2 via the COGITARE channel established between them. It can be empty (and therefore contain no parameters), or alternatively contain one or more parameters specifying the request from CGN#1, such as for example a parameter named here "requested-size" indicating a preference regarding the size of the IP address space to be delegated, or equivalently a parameter named here "requested-nb" indicating a number of desired delegated addresses, a parameter named here "requested-af" indicating the type of desired delegated IP addresses (for example, set to 0 for IPv4 addresses and to 1 for IPv6 addresses, the absence of this parameter can be considered equivalent to a setting of the parameter to 0, i.e. as designating IPv4 addresses), etc.

[0119] Thus, for illustration purposes, an IP_RESOURCE_DELEGATE frame including a "requested-size" parameter valued at 32 (bits) and not containing a "requested-af" parameter indicates a request to delegate a single IPv4 address (the "requested-size" parameter combined with the absence of a "requested-af" parameter in fact indicates a desired number of delegated IP addresses). Of course, other parameters can be included in the IP_RESOURCE_DELEGATE delegation request, such as, for example, a desired delegation duration, etc.

[0120] Referring to Figure 7, the IP_RESOURCE_DELEGATE frame is received by CGN#2, by its receiving module 9, via the COGITARE channel established with CGN#1 (step F10).

[0121] If CGN#2 accepts CGN#1's delegation request (yes response to test step F20), it establishes an "address-list" of IP addresses including at least one available IP address, selected from the POOL#2 set that CGN#2 manages and that it is ready to delegate to CGN#1 (step F40). It should be noted that the IP addresses delegated to CGN#1 are intended to be used by it to process messages from client equipment attached to it; they must therefore not be used to process messages exchanged within the framework of active connections of client equipment served by CGN#2, nor for future connections.Apart from the absence of traffic associated with the IP addresses in the "address-list", CGN#2 may consider other criteria for selecting the addresses from the POOL#2 set that it agrees to delegate to CGN#1: for example, it may select them randomly from among the unused addresses (i.e., those that are not active) in the POOL#2 set, or select those that do not belong to a "block-list", etc. CGN#2 may also, in establishing the "address-list", take into account the preferences of CGN#1 indicated, if applicable, in its delegation request (see "requested-size", "requested-nb", "requested-af" parameters, etc.). Alternatively, CGN#2 may be configured to ignore, when establishing the "address-list", the preferences indicated by CGN#1.

[0122] In the embodiment described herein, as detailed further below, after delegating an IP address from the POOL#2 set to CGN#1, CGN#2 continues to be involved in managing traffic intended for or sent using this IP address. More particularly, it is configured to encapsulate, via its transmission / reception module 11, in the COGITARE channel established with CGN#1, all packets it receives destined for this delegated IP address to transmit them to CGN#1, and conversely, decapsulate packets using this delegated IP address that it receives via the COGITARE channel established with CGN#1 to transmit them to their respective recipients. During these operations, CGN#2 is configured not to perform any translation of the delegated IP address (unlike what it does with the IP addresses from the POOL#2 set whose use is reserved for it, i.e. which are not delegated to any other NAT operator).This embodiment advantageously makes it possible to avoid updating the routing tables in network 2, since CGN#2 continues to manage the traffic associated with the IP addresses that it delegates to other NAT operators of system 1.

[0123] Once the "address-list" list is established, CGN#2 stores in a table named DELEG here stored for example in its non-volatile memory NVM, the IP addresses of the "address-list" list delegated to CGN#1 in association with an identifier of CGN#1, for example its IP address @IP-CGN#1.

[0124] CGN#2 then sends, via its sending module 10 and via the COGITARE channel established with CGN#1, a favorable response to the delegation request from CGN#1 including the “address-list” list thus established (step F50). In the embodiment described here of a COGITARE channel based on the QUIC protocol, the response from CGN#2 is an IP_RESOURCE_DELEGATE frame including the “address-list” list. This response may also include other information, such as for example a parameter named here “validity” indicating the duration for which the IP addresses of the “address-list” list are delegated to CGN#1, a parameter named here “rate-limit” representative of the maximum volume of traffic associated with the use of a delegated IP address from the “address-list” list that CGN#2 can manage (taking into account the fact that it remains involved in the management of this traffic as indicated previously), etc.

[0125] The IP_RESOURCE_DELEGATE response from CGN#2 is received by CGN#1, and transmitted to its execution module 5 (step E50-3). The execution module 5 then records in a CGN_PEERS table, stored for example in the non-volatile memory NVM, the delegation offer(s) received from the NAT operator(s) to which it sent a delegation request in step E50-2, in other words, in the illustrative example considered here of CGN#2 (step E50-4).More particularly, in the embodiment described here, the CGN#1 execution module 5 stores in the CGN_PEERS table, for each operator NAT having delegated IP addresses to it (i.e. in the example envisaged, for CGN#2): an identifier of the operator NAT (i.e. in the example envisaged, an identifier of CGN#2); the list of addresses delegated by the operator NAT (i.e. in the example envisaged, the “address-list” list); the validity period of the delegation of addresses by the operator NAT (i.e. in the example envisaged, the duration indicated by CGN#2 in the “validity” parameter); and the maximum volume of traffic associated with the addresses delegated by the operator NAT that can be managed by it (i.e. in the example envisaged, the volume indicated by CGN#2 in the “rate-limit” parameter).

[0126] For the sake of simplification here, we assume the same value for validity period and maximum volume for all IP addresses in the "address-list". However, this assumption is not limiting in itself and we can consider values ​​that differ depending on the delegated IP addresses.

[0127] From then on, CGN#1 is able to use the delegated IP addresses listed in the CGN_PEERS table in addition to the IP addresses of the POOL#1 set (except those removed where applicable during the execution of the ACT1 action) to process the packets from the client equipment that it receives (step E50-5). Thus, thanks to the invention, the POOL#1 set that CGN#1 benefits from is de facto extended to process the packets that reach it.

[0128] If the IP addresses delegated to CGN#1 have a limited validity period, then CGN#1 is configured locally to use these delegated IP addresses only for a period of time less than or equal to this validity period. If CGN#1 needs to use a delegated IP address beyond the validity period specified by CGN#2, then CGN#1 can be configured to request CGN#2 for an extension of this validity period or to request another NAT operator of system 1 to delegate other IP addresses and return, if necessary, the delegated IP address(es) whose validity period has expired to CGN#2. Note that CGN#1 can return an IP address delegated by CGN#2 before the expiration of its validity period, for example by sending a QUIC frame to CGN#2 introduced for the purposes of the invention called for example RELEASE_RESOURCES and including the delegated IP address in question.

[0129] If no validity period is specified, CGN#1's use of a delegated IP address may be limited to a default period of time (e.g., 24 hours), or as long as CGN#1 needs the delegated IP address in question (e.g., as long as detection module 4 associates dishonest behavior with the bad@IP address), or as long as CGN#1 is not notified to cease such use (e.g., by CGN#2 or by network 2 operator OP2), etc.

[0130] Furthermore, as mentioned previously, in the embodiment described here, the traffic associated with an IP address delegated to CGN#1 by CGN#2 continues to transit through CGN#2 via the COGITARE channel established between the two operator NATs. As a result, CGN#1 is configured to send to CGN#2, via its transmission / reception module 8, all the packets that it processes and for which it has selected an IP address delegated by CGN#2.

[0131] Furthermore, if a maximum volume of traffic that can be managed by CGN#2 has been indicated to CGN#1 (typically via the “rate-limit” parameter), CGN#1 is preferentially configured to respect this maximum volume, for example it can be configured to distribute the traffic associated with distinct client equipment over several CO-GTTARE channels, and therefore select for these distinct client equipment IP addresses delegated by operator NATs distinct from system 1. CGN#2 can furthermore be configured to clip the traffic associated with the IP addresses delegated to CGN#1 beyond the maximum volume indicated, if this maximum volume is not respected by CGN#1.

[0132] Figure 8 illustrates with an example what has just been described, and more specifically how CGN#1 and CGN#2 process packets associated with an IP address delegated by CGN#2 to CGN#1. For the sake of simplification, only the operator NATs CGN#1 and CGN#2 of system 1 are represented by Figure 8.

[0133] It is assumed with this figure that after execution of the action ACT3, CGN#1 receives a packet M1 from a client device 14 to which an internal IPv4 address noted @IP14 and a port number P14 are allocated, for example @IP14= 10.2.25.5 and P14= 12345. The packet M1 carries data sent by the client device 14 and intended for a destination entity, for example here a server 15 identified by a destination IPv4 address noted @IP15 and a destination port number noted P15; for example @IP15=1.2.3.4, P15=9856.

[0134] The Ml packet sent by the client equipment 14 is received by CGN#1; it is therefore received by CGN#1 and the packet header contains the source IP address and the internal port number @IP14 and P14.

[0135] Upon receipt of the Ml packet, CGN#1 via its management module 12 consults the BIB table stored in its non-volatile memory NVM and determines whether an entry corresponding to the pair (@IP14,P14) already exists in the table.

[0136] If no matching entry exists in the BIB table, the management module 12 selects an external IP address and, in the example considered here, an external port number, denoted respectively @IP14ext and P14ext, to process the packet M1 coming from the client equipment 14 (note however that the port number P14 is not necessarily modified by the management module 12). The IP address @IP14ext is selected here from the IP addresses delegated by CGN#2 listed in the CGN_PEERS table. A new entry is then created by the management module 12 in the BIB table associating the pair (@IP14, P14) with the pair (@IP14ext, P14ext). For the sake of simplification here, it is assumed that the address @IP14ext is associated in the BIB table only with the internal IP address @IP14.

[0137] If an entry that matches this packet exists in the BIB table, the management module 12 extracts the external IP address and port number (@IP14ext, P14ext) entered for this entry in the BIB table.

[0138] In the following, we consider @IP14ext=25.25.65.2 and P14ext=4859 for illustrative purposes.

[0139] CGN#1 then translates the internal IP address @IP14 and port number P14 of the M1 packet to the external IP address @IP14ext and port number P14ext (i.e., it replaces in the packet header @IP14 and P14 with @IP14ext and P14ext respectively), resulting in a modified packet M1'. It should be noted that as mentioned earlier, further modifications can be made by CGN#1 to the M1 packet. However, for the sake of simplicity, such modifications are not described further here.

[0140] Then, in the embodiment described here, it encapsulates the M1' packet in a QUIC M2 packet (also commonly referred to as a QUIC M2 frame) having as its source IP address the external IP address @IP-CGN#1 of CGN#1, for example @IP-CGN#1 = 11.12.13.14. The port number used, noted PI, can be a port number chosen randomly when establishing the COGITARE channel with CGN#2, as described for example in the document RFC 6056 entitled "Recommendations for Transport-Protocol Port Randomization", January 2011. It should be noted that in the example considered here of a QUIC communication channel established between CGN#1 and CGN#2, it is the CID identifier of the connection established between the two NAT operators which is used by the latter, and the port number used is of little importance.

[0141] As the external IP address @IP14ext selected by CGN#1 to process the packet M1 is an IP address delegated by CGN#2, CGN#1 transmits the frame M2 to CGN#2 via its transmission / reception module 8 via the COGITARE channel established between the two operator NATs, so that the data carried by the packet M1' (or equivalently by the packet M1) are routed by CGN#2 to their recipient, i.e. to the server S. The M2 frame therefore has in its header as the recipient IP address, the external IP address @IP-CGN#2 of CGN#2.

[0142] Upon receipt of the M2 frame, CGN#2 checks, using its DELEG table, whether the source IP address (i.e. here the @IP-CGN#1 address) corresponds to an IP address in its POOL#2 set delegated to CGN#1, the M2 frame being received via the COGITARE channel established with CGN#1.

[0143] If this is not the case (e.g. no entry in the DELEG table corresponding to the source IP address @IP-CGN#1 of the M2 frame), CGN#2 drops the M2 frame.

[0144] If this is the case, CGN#2 decapsulates the Ml' packet from the M2 frame and then transmits the Ml' packet to its recipient, i.e. to the server S, without performing any address translation on the Ml' packet. The Ml' packet transmitted to the server S therefore has, in its header: as source IP address and port number: the external IP address @IP14ext=25.25.65.2 delegated by CGN#2 to CGN#1 and the external port number P14ext=4859; and as destination IP address and port number: the IP address @IP15=1.2.3.4 and the port number @P15=9856.

[0145] Now assume that server S responds to client device 14 by sending it an M3 packet containing data. The M3 packet is sent by server S with the source IP address @IP15=1.2.3.4 and the source port number @P15=9856. The data is intended for client device 14 and therefore for the external IP address @IP14ext=25.25.65.2 delegated by CGN#2 to CGN#1 and the external port number P14ext=4859.

[0146] Since the M3 packet is intended for an IP address in the POOL#2 set managed by CGN#2, it is, in the embodiment described here, sent to CGN#2.

[0147] Upon receipt of the M3 packet, CGN#2 checks whether the destination IP address of the M3 packet is an IP address from the POOL#2 set of IP addresses that it manages and delegated to another NAT operator of system 1. It uses its DELEG table for this purpose.

[0148] If it finds no matching entry for @IP14ext in the DELEG table, but it is indeed an IP address belonging to the POOL#2 set, CGN#2 processes the M3 packet according to a conventional NAT44 procedure, and translates the external IP address @IP14ext and the external port number P14ext into an internal IP address and an internal port number if an entry is locally active in its BIB table.

[0149] If an entry in the DELEG table is found by CGN#2, then in the embodiment described here it encapsulates the M3 packet in a QUIC M4 frame (packet in the sense of the invention) without modifying the destination IP address (i.e. the @IP14ext address) of the M3 packet encapsulated in the M4 frame, and therefore incidentally without modifying the data that the M3 packet contains. It then transmits the M4 frame to CGN#1 via its transmission / reception module 11, via the COGITARE channel established between the two operator NATs. The M4 frame contains the M3 packet (in particular the data sent by the server S and intended for the client equipment 14), and has in its header as source IP address, the IP address @IP-CGN#2 of CGN#2, and as destination IP address, the IP address @IP-CGN#1 of CGN#1. For the sake of simplification, we omit here the port numbers used between CGN#1 and CGN#2, for the reasons mentioned previously.

[0150] Upon receipt of the M4 frame, CGN#1 checks that the source IP address @IP-CGN#2 of the M4 frame matches an entry in its CGN_PEERS table. If it does not, the M4 frame is discarded.

[0151] If the source IP address @IP-CGN#2 of the M4 frame matches an entry in the CGN_PEERS table, CGN#1 extracts the M3 packet from the M4 frame. Then it checks its BIB table to see if an entry matching the destination IP address of the M3 packet (i.e., here, the external IP address @IP14ext) exists.

[0152] If no entry exists in the BIB table for this IP address, CGN#1 drops the M3 packet.

[0153] If an entry exists (i.e. this IP address was previously selected by CGN#1 to process messages from a client device or an entry in the BIB table was explicitly created using a dedicated interface), it replaces in the M3 packet the destination @IP14ext address and P14ext port number with the internal IP address and port number associated with them in the BIB table, in this case here by the internal IP address @IP14 and by the internal port number P14 of the client equipment 14.

[0154] Then the modified M3 packet, designated in the following by M3', is transmitted to the client equipment 14 by CGN#1.

[0155] It should be noted that what has just been described for COGITARE channels based on the QUIC protocol can be applied identically to COGITARE channels based on another protocol, as long as the encapsulation of the M1' and M3 packets is carried out in messages conforming to this other protocol. For example, for the IP-in-IP protocol, it is appropriate to encapsulate the M1' and M3 packets in IP packets instead of encapsulating them in QUIC frames.

[0156] In the example of Figure 2, the client equipment of the network 2 are terminals communicating directly with the operator NATs of the system 1. As mentioned previously, it is possible to envisage applying the invention to other types of client equipment of the network 2 and in particular to equipment for accessing the network 2 such as CPEs connecting, for example, terminals connected to a local area network (LAN) to the network 2. In this case, the invention is applied in a manner identical to that which has just been described for client equipment of the terminal type at a CPE. However, as mentioned previously, there is an additional address translation step at the CPE, known per se.

[0157] Figure 9 illustrates this additional step. More precisely, the client equipment 14 of Figure 9 is now a CPE (instead of a terminal as indicated in Figure 8), used as network access equipment 2 by a terminal 16 connected to a LAN. The invention is applied by the CGN#1 and CGN#2 in an identical manner to what was described with reference to Figure 8 for the terminal 14. In Figure 9, the packet M1 however results from a modification by the CPE 14 of a packet M1_0 sent by the terminal 16 containing data intended for the server S, this packet M1_0 having as its source IP address and port number, an internal IP address and port number noted respectively @IP16 and P16, allocated by the CPE 14 to the terminal 16.The modification made by CPE 14 to packet Ml_0, resulting in packet Ml, consists of replacing in the header of packet Ml_0 the internal IP address @IP16 and port number P16 with the IP address @IP14 and port number P14 allocated to CPE 14. The reverse modification is applied by CPE 14 to packet M3' resulting in packet M3" then sent to terminal 16.

[0158] Everything that has just been described with reference to Figures 2 to 9 for the operator NATs CGN#1 and CGN#2 can be applied in a similar or identical way to the other operator NATs of system 1. In addition, the operator NAT CGN#1 can obtain IP addresses delegated by several operator NATs of system 1. What has just been described for CGN#2 then applies in a similar or identical way to the different operator NATs delegating IP addresses to CGN#1.

[0159] In the embodiment described with reference to Figures 2 to 9, the system 1 is configured so that when a NAT operator CGN#j of the system 1 delegates one or more IP addresses to a NAT operator CGN#k, with k*j, CGN#j continues to receive the traffic associated with these delegated IP addresses. In other words, the routing tables maintained by the routers of the network 2 are not modified, which allows CGN#k to use the IP addresses that have been delegated to it without delay, and this in a transparent manner for the client equipment that it serves. In another embodiment, it can be envisaged that following the delegation of IP addresses by CGN#j to CGN#k, the routing tables routing are modified so that the traffic associated with these delegated IP addresses (incoming and outgoing) is routed directly to CGN#j (without passing through the COGITARE channel established between CGN#j and CGN#k), for the duration of the delegation.

[0160] In the embodiment described with reference to Figures 2 to 9, it is assumed that a single level of operator NAT is deployed in the network. However, the invention also applies in a context where several levels (or stages) of operator NAT are deployed in the network 2 (inducing several successive address translations applied to the messages passing through the network). In such a context, the delegation of IP addresses is carried out in accordance with the invention, in a manner identical to that which has just been described, between operator NATs belonging to the same level.

[0161] Figure 10 illustrates an example of a network 2' comprising two levels of NAT operators LEV1 and LEV2, the level LEV1 comprising I NAT operator CGN l#m, m = l,..,I, forming a system 1-1 according to the invention and the level LEV2 comprising J NAT operator CGN2#k, k= l,...,J, forming a system 1-2 according to the invention, I and J designating integers greater than 1. In each level LEVi, i=l,2, each NAT operator of the system 1-i comprises the functional modules 4 to 13 previously described and is capable of acting, depending on the context, as a first device or a second device according to the invention. The management and collaboration methods according to the invention which have just been described with reference to the NAT operators CGN#n, n= l,...,M, of figures 2 to 9 therefore apply in a similar or identical manner within each LEVi level and more particularly within each 1-i system in accordance with the invention, i=l,2, between the NAT operators of this system.In other words, each CGNi#p operator NAT of the 1-i system deployed at the LEVi level is likely to request a delegation of IP addresses or to delegate one or more IP addresses to one or more CGNi#t operator NATs, with t*p, belonging to the same 1-i system and therefore to the same LEVi level as it. COGITARE channels (represented by double arrows in Figure 10) can thus be established between operator NATs of the same level.

[0162] Figure 10 illustrates different situations experienced by systems 1-1 and 1-2 in network 2'.

[0163] More precisely, Figure 10a illustrates the state of network 2' and systems 1-1 and 1-2 in a normal state (nominal conditions). Each operator NAT within a system 1-i, i= 1,2 manages a set of distinct IP addresses and uses the addresses it manages to process the packets of the customer equipment it serves (CPE or terminals in the example of Figure 10). Each packet from a customer equipment (emitted or destined for the latter) passes successively in network 2' through two operator NATs belonging respectively to the LEVI level and to the LEV2 level. Each operator NAT selects to process this packet an IP address in the POOL space of IP addresses assigned to it. Thus, for illustration purposes in Figure 10a, a message associated with a terminal 17 passes through the NAT operator CGN1#1 in the system 1-1 and through the NAT operator CGN2#2 in the system 1-2.

[0164] Figure 10b illustrates a situation in which the detection module 4 of a CGN1#m of the system 1-1, for example CGN1#1, detects malicious behavior associated with an address that it manages and sends via its execution module 5, in response to this malicious behavior, a request for delegation of at least one IP address to another NAT operator of the system 1-1, for example to CGN1#2. In the example of Figure 10b, following the delegation of at least one IP address by CGN1#2 to CGN1#1, CGN1#1 selects one of the IP addresses delegated by CGN1#2 to process the packets associated with terminal 17. These messages, when they contain data sent by terminal 17 and intended for a server 18, pass through CGN1#1 which replaces their internal IP address with an IP address delegated by CGN1#2 (or vice versa), then sends them via the COGITARE channel to CGN1#2 so that they can be sent to server 18. In accordance with the routing rules established in network 2, the packets are transmitted by CGN1#2 to a NAT operator of system 1-2 deployed at LEV2 level (CGN1#2 then performing no address translation for the packets in question), for example to CGN2#2, in charge of applying to the packets received from CGN1#2 a new address translation step before they are routed to server 18.Packets sent by server 18 containing data intended for terminal 17 follow the reverse path: they pass through CGN2#2 which performs an address translation, then are sent by CGN2#2 to CGN1#2 which in turn transmits them, in the COGITARE channel, to CGN1#1 without performing an address translation. CGN1#1, after replacing the delegated external IP address used for the packets with an internal IP address allocated to terminal 17, sends these packets to terminal 17.

[0165] Figure 10c illustrates a situation in which, in each system 1-i deployed at each LEVi level, malicious behavior associated with an IP address managed by a NAT operator of system 1-i is detected, triggering an IP address delegation request and an IP address delegation at each level. In the example illustrated by Figure 10c, malicious behavior associated with an IP address managed by the NAT operator CGN1#I of system 1-1 and malicious behavior associated with an IP address managed by the NAT operator CGN2#2 of system 1-2 are detected, resulting in an IP address delegation by CGN1#1 to CGN1#I and an IP address delegation by CGN2#J to CGN2#2.

[0166] Of course, the invention is not limited to two levels of operator NAT deployed in the network, a greater number of NAT levels can be envisaged, the invention applying in the same way as what was previously described with reference to figures 2 to 9 independently at each level.

[0167] Finally, the invention has been described with reference to operator NATs. However, the invention can be applied to other devices managing a plurality of IP addresses that may be shared between several client devices, such as, for example, devices implementing a proxy function using its own IP addresses to relay received messages. Such devices are for example described in sections 5, 6 and 7 of the RFC 7620 document mentioned above. The invention also applies when the IP addresses managed by the first and / or second devices are not shared between several client devices.

Claims

Claims

1. Method for managing, by a first device (CGN#1; CGN1#1; CGN1#1, CGN2#2) located in a network (2,2'), a first set of IP addresses, said method comprising: a step (E30) of detecting suspicious behavior associated with an IP address (bad@IP) of said first set selected by the first device to process at least one data packet from a client equipment (14,17) served by the first device; a step (E50) of executing, following said detection, at least one action from: o an adjustment (ACT2) of at least one sharing rate of at least one IP address of the first set applied by the first device; o a request (ACT3), addressed to at least one second device (CGN#2; CGN1#2;CGN1#1, CGN2#J) managing a second set of IP addresses, delegating at least one IP address from the second set to the first device so that the first device can select said at least one delegated IP address to process at least one data packet from at least one client device served by the first device.;

2. Management method according to claim 1 wherein the detection step (E30) comprises receiving a notification from an attack detection function (DMS) or from an IP address reputation system (REP_SYS).

3. Management method according to claim 1 or 2 further comprising a step (E10) of discovering said at least one second device.

4. Management method according to any one of claims 1 to 3 further comprising a step (E20) of establishing with said at least one second device at least one communication channel.

5. Management method according to claim 4 wherein said at least one communication channel is an encrypted communication channel based on the QUIC protocol.

6. Management method according to one of claims 1 to 5 wherein said delegation request comprises a desired number and / or type of delegated IP addresses.

7. Management method according to one of claims 1 to 6 further comprising a step (E50-3) of receiving, in response to a said delegation request addressed by the first device to a said second device, at least one element from: a list comprising at least one IP address delegated by this second device to the first device; a duration during which said list is delegated to the first device; information representative of a maximum volume of traffic associated with the use of an IP address delegated by said second device to the first device that can be managed by the second device.

8. Management method according to any one of claims 1 to 7 further comprising: a step of receiving, from an internal source IP address (@IP14), a first data packet (Ml) comprising data intended for a destination entity (15); a step of replacing said internal source IP address (@IP14) with a said delegated IP address (@IP14ext) by a said second device (CGN#2) to the first device (CGN#1) and selected by the first device to process said first data packet (Ml); and a step of transmitting said data (Ml') with said delegated IP address (@IP14ext) to said second device (CGN#2), via a communication channel established with it, so that said data is routed to the destination entity (15).

9. Management method according to any one of claims 1 to 8 further comprising: a step of receiving, via a communication channel established with a said second device (CGN#2), a second data packet (M3) transmitted by a transmitting entity (15) and comprising data intended for an IP address (@IP14ext) of the second set of IP addresses managed by the second device (CGN#2); if said IP address (@IP14ext) is delegated to the first device (CGN#1) by the second device and selected by the first device to process data packets of a client equipment (14) served by the first device, a step of transmitting said data to an internal IP address (@IP14) allocated to said client equipment.

10. Management method according to any one of claims 1 to 9 comprising a step of selecting at least two IP addresses delegated by said second separate devices to process data packets from at least two separate client devices

11. Management method according to claim 3 or 4 in which the step (E10) of discovery and / or the step (E20) of establishment of said communication channel is implemented before the step (E30) of detection.

12. Method for collaborating with a first device (CGN#1; CGN1#2; CGN1#I, CGN2#2) located in a network (2) and managing a first set of IP addresses comprising an IP address (bad@IP) associated with suspicious behavior, said method being intended to be implemented by a second device (CGN#2; CGN1#2; CGN1#1, CGN2#J) managing a second set of IP addresses and comprising: a step (F10) of receiving, from the first device, a request to delegate at least one IP address from the second set to the first device so that the first device can select said at least one delegated IP address to process at least one data packet from at least one client device served by the first device; and a step (F50) of sending to the first device a list comprising at least one IP address from the second set delegated by said second device to the first device.

13. Collaboration method according to claim 12 further comprising: a step of receiving, via a communication channel established with the first device, a first data packet (M2) comprising data intended for a recipient entity (15) and transmitted with a source IP address (@IP14ext) belonging to the second set of IP addresses managed by the second device (CGN#2); if said source IP address (@IP14ext) is a said IP address delegated by the second device to the first device, a step of transmitting said data to the recipient entity (15) without modifying said source IP address (@IP14ext) of said data.

14. Collaboration method according to claim 12 or 13 further comprising: a step of receiving a second data packet (M3) comprising data transmitted by a transmitting entity (15) and intended for a destination IP address (@IP14ext) belonging to the second set of IP addresses managed by the second device (CGN#2); if said IP address (@IP14ext) is a said IP address delegated by the second device to the first device, a step of transmitting said data to the first device via a communication channel established with said first device without modifying said destination IP address (@IP14ext) of said data.

15. Computer program (PROG1, PROG2) comprising instructions for implementing a management method or a collaboration method according to any one of claims 1 to 14 when said program is executed by a computer (3).

16. Device, called first device (CGN#1), located in a network (2), said first device managing a first set of IP addresses and comprising: a detection module (4), configured to detect suspicious behavior associated with an IP address of said first set selected by the first device to process at least one data packet from a client equipment served by the first device; an execution module (5) configured to execute, following said detection, at least one action among: o an adjustment of at least one sharing rate of at least one IP address of the first set applied by the first device; o a request, addressed to at least one second device managing a second set of IP addresses, to delegate at least one IP address of the second set to the first device so that the first device can select said at least one delegated IP address to process at least one data packet from at least one client device served by the first device.

17. Device, called second device (CGN#2), located in a network (2), said second device managing a second set of IP addresses and comprising: a receiving module (9), configured to receive, from a first device managing a first set of IP addresses comprising an IP address associated with suspicious behavior, a request to delegate at least one IP address from the second set to the first device so that the first device can select said at least one delegated IP address to process at least one data packet from at least one client device served by the first device; and a sending module (10), configured to send to the first device, a list comprising at least one IP address from the second set delegated by said second device to the first device.

18. System (1, 1-1, 1-2) comprising: at least one first device (CGN#1, CGN1#1, CGN1#I, CGN2#2) according to claim 16; and at least one second device (CGN#2, CGN1#2, CGN1#1, CGN2#J) according to claim 17, configured to process at least one request for delegation of IP addresses received from a said first device.

Images