WO2024121281A1 - Procédé de gestion d'un ensemble d'adresses ip, procédé de collaboration et dispositifs configurés pour mettre en œuvre ces procédés - Google Patents
Procédé de gestion d'un ensemble d'adresses ip, procédé de collaboration et dispositifs configurés pour mettre en œuvre ces procédés Download PDFInfo
- Publication number
- WO2024121281A1 WO2024121281A1 PCT/EP2023/084648 EP2023084648W WO2024121281A1 WO 2024121281 A1 WO2024121281 A1 WO 2024121281A1 EP 2023084648 W EP2023084648 W EP 2023084648W WO 2024121281 A1 WO2024121281 A1 WO 2024121281A1
- Authority
- WO
- WIPO (PCT)
- Prior art keywords
- address
- cgn
- addresses
- operator
- nat
- Prior art date
Links
- 238000000034 method Methods 0.000 title claims abstract description 92
- 230000008569 process Effects 0.000 claims abstract description 60
- 230000009471 action Effects 0.000 claims abstract description 58
- 238000007726 management method Methods 0.000 claims abstract description 43
- 238000004891 communication Methods 0.000 claims description 36
- 238000001514 detection method Methods 0.000 claims description 35
- 101100384801 Bos taurus CGN1 gene Proteins 0.000 claims description 31
- 101100221143 Rattus norvegicus Cnga4 gene Proteins 0.000 claims description 19
- 230000004044 response Effects 0.000 claims description 15
- 230000005540 biological transmission Effects 0.000 claims description 8
- 238000004590 computer program Methods 0.000 claims description 7
- 230000006399 behavior Effects 0.000 description 47
- 238000011330 nucleic acid test Methods 0.000 description 33
- 238000013519 translation Methods 0.000 description 26
- 230000014616 translation Effects 0.000 description 26
- 230000006870 function Effects 0.000 description 25
- 229920006235 chlorinated polyethylene elastomer Polymers 0.000 description 15
- 230000007246 mechanism Effects 0.000 description 12
- 101000908384 Bos taurus Dipeptidyl peptidase 4 Proteins 0.000 description 11
- HEFNNWSXXWATRW-UHFFFAOYSA-N Ibuprofen Chemical compound CC(C)CC1=CC=C(C(C)C(O)=O)C=C1 HEFNNWSXXWATRW-UHFFFAOYSA-N 0.000 description 11
- 230000000116 mitigating effect Effects 0.000 description 10
- 238000012986 modification Methods 0.000 description 8
- 230000004048 modification Effects 0.000 description 8
- 102100031102 C-C motif chemokine 4 Human genes 0.000 description 6
- 101000777470 Mus musculus C-C motif chemokine 4 Proteins 0.000 description 6
- 230000008901 benefit Effects 0.000 description 6
- 101100042631 Saccharomyces cerevisiae (strain ATCC 204508 / S288c) SIN3 gene Proteins 0.000 description 5
- 238000012936 correction and preventive action Methods 0.000 description 5
- 102100026620 E3 ubiquitin ligase TRAF3IP2 Human genes 0.000 description 4
- 101710140859 E3 ubiquitin ligase TRAF3IP2 Proteins 0.000 description 4
- 238000012545 processing Methods 0.000 description 4
- 230000000694 effects Effects 0.000 description 3
- 230000003287 optical effect Effects 0.000 description 3
- 102220037233 rs115173026 Human genes 0.000 description 3
- 101100322249 Caenorhabditis elegans lev-1 gene Proteins 0.000 description 2
- 238000006243 chemical reaction Methods 0.000 description 2
- 238000000136 cloud-point extraction Methods 0.000 description 2
- 238000005538 encapsulation Methods 0.000 description 2
- 239000000284 extract Substances 0.000 description 2
- 230000011664 signaling Effects 0.000 description 2
- 230000007727 signaling mechanism Effects 0.000 description 2
- 230000008093 supporting effect Effects 0.000 description 2
- 238000012360 testing method Methods 0.000 description 2
- 230000001010 compromised effect Effects 0.000 description 1
- 230000003750 conditioning effect Effects 0.000 description 1
- 125000004122 cyclic group Chemical group 0.000 description 1
- 230000004069 differentiation Effects 0.000 description 1
- 230000002349 favourable effect Effects 0.000 description 1
- 238000001914 filtration Methods 0.000 description 1
- 230000003116 impacting effect Effects 0.000 description 1
- 230000001939 inductive effect Effects 0.000 description 1
- 238000007689 inspection Methods 0.000 description 1
- 238000012423 maintenance Methods 0.000 description 1
- 238000004377 microelectronic Methods 0.000 description 1
- 238000013508 migration Methods 0.000 description 1
- 230000005012 migration Effects 0.000 description 1
- 230000035484 reaction time Effects 0.000 description 1
- 102220031198 rs187960531 Human genes 0.000 description 1
- 230000001960 triggered effect Effects 0.000 description 1
- 230000005641 tunneling Effects 0.000 description 1
- 238000012795 verification Methods 0.000 description 1
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/14—Network architectures or network communication protocols for network security for detecting or protecting against malicious traffic
- H04L63/1441—Countermeasures against malicious traffic
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L61/00—Network arrangements, protocols or services for addressing or naming
- H04L61/09—Mapping addresses
- H04L61/25—Mapping addresses of the same type
- H04L61/2503—Translation of Internet protocol [IP] addresses
- H04L61/2514—Translation of Internet protocol [IP] addresses between local and global IP addresses
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L61/00—Network arrangements, protocols or services for addressing or naming
- H04L61/09—Mapping addresses
- H04L61/25—Mapping addresses of the same type
- H04L61/2503—Translation of Internet protocol [IP] addresses
- H04L61/2521—Translation architectures other than single NAT servers
- H04L61/2532—Clique of NAT servers
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L61/00—Network arrangements, protocols or services for addressing or naming
- H04L61/09—Mapping addresses
- H04L61/25—Mapping addresses of the same type
- H04L61/2503—Translation of Internet protocol [IP] addresses
- H04L61/2517—Translation of Internet protocol [IP] addresses using port numbers
Definitions
- Title of the invention Method for managing a set of IP addresses, collaboration method and devices configured to implement these methods.
- the invention belongs to the general field of telecommunications.
- a DDoS attack is an attempt to make resources (for example computing resources or network resources) unavailable for their users.
- resources for example computing resources or network resources
- Such attacks can be massive and likely to compromise several hundred thousand client devices (for example terminals), which can in turn be used as relays to amplify the harmful power of the attacks.
- client devices for example terminals
- These attacks are becoming more and more frequent and intense; their magnitude in terms of duration but also of extent and propagation makes it difficult for the DPS service(s) deployed in the network to detect and mitigate such attacks (for example via a quarantine of resources targeted by attacks, filtering of traffic associated with an attack, etc.).
- NAT Network Address Translation
- CGN Carrier Grade NAT
- LSN Large Scale NAT
- 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.
- a translation function also called translation
- IP addresses and where applicable, port numbers
- Several types of operator NAT have been specified by the IETF (for “Internet Engineering Task Force” in English) and deployed by operators (for example NAT 4, NAT64, DS-Lite, NPTv6, etc.).
- 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” in English).
- Network architectures based on the exploitation of CGN make it possible in particular to set up an IP address sharing mechanism, offering for example a service continuity solution in a context of shortage of IPv4 addresses.
- 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 address IPv4 in the case of double NAT engineering, in particular) at the connection interface of the access equipment (for example a CPE) of the client 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 NAT operator (CGN).
- Figure 1 illustrates, in an example, the different address translations carried out respectively by access equipment CPE1 and by a NAT CGN2 operator on IP data packets transmitted by a terminal H3, connected for example to a company network or a home network, and intended for remote equipment S4.
- an IP data packet P having the source IP address 10.2.25.5 and a source port number 12345 is transmitted by the terminal H, and received by the equipment CPE1 access.
- the private IP address 192.168.1.56 and the port number 16587 are assigned to the WAN interface (for “Wide Area Network” in English) of the CPE1 access equipment in the case of engineering double NAT.
- the NAT function of the access equipment CPE1 then replaces in the header of the IP data packet P received from the terminal H3, the pair (10.2.25.5,12345) with the pair (192.168.1.56,16587).
- the access equipment CPE1 sends the IP data packet P' of which at least the source address field has been modified after execution of the NAT function to a NAT operator CGN2.
- CRC cyclic redundancy code
- ALG Application Level Gateway
- the NAT operator CGN2 On receipt of the IP data packet P', the NAT operator CGN2 selects an external IP address (for example a public IPv4 address) and an external port number (for example a public port number) for processing the packet P', for example the couple (1.2.3.4, 45875), and associates in an information base, for example a BIB base (for “Binding Information Base”) the couple (1.2.3.4, 45875) with the couple (192.168.1.56, 16587) as well as the transport protocol used (not mentioned in Figure 1 for the sake of simplification).
- an external IP address for example a public IPv4 address
- an external port number for example a public port number
- an information base for example a BIB base (for “Binding Information Base”) the couple (1.2.3.4, 45875) with the couple (192.168.1.56, 16587) as well as the transport protocol used (not mentioned in Figure 1 for the sake of simplification).
- the NAT operator CGN2 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 IP data packet P" thus obtained is then transferred by the NAT operator CGN2 to its destination (the remote equipment S4 in the figure).
- IPv4 addresses are a problem also encountered in mobile networks, due to the limitation of 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 who implement such engineering must therefore also set up mechanisms for sharing private IPv4 addresses based on operator NATs (CGN) typically deployed at the level of 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).
- CGN operator NATs
- NAT64 type conversion mechanisms can also be deployed in the networks of operators who 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 a so-called IPv6-only node supporting only the IPv6 protocol to communicate with a so-called IPv4-only node supporting only the IPv4 protocol, by converting the IPv6 data packets received from the IPv6-node. only into IPv4 packets before forwarding them to the IPv4-only node.
- the invention makes it possible in particular to improve the effectiveness of attack mitigation policies in network environments where functions which aggregate several connections using addresses capable of being shared (for example CGN or proxy functions) are deployed, by proposing a method of management, by a first device located in a network, of 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 of client equipment served by the first device; following said detection, a step of executing 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; and o a request, addressed to at least one second device managing a second set of IP addresses, for delegation of 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 equipment served by the first device.
- the invention also relates to a device, called a 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 a IP address of said first set selected by the first device to process at least one data packet from client equipment served by the first device; an execution module, 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; and o a request, addressed to at least one second device managing a second set of IP addresses, for delegation of 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 equipment served by the first device.
- a detection module configured to detect suspicious behavior associated with a IP address of said first set selected by the first device to process at least one data packet from client equipment served by the first device
- an execution module configured to execute following said detection, at least one action among:
- the first and second devices can typically be operator NATs (or CGN or even LSN) as described previously, configured to manage distinct pools of IP addresses (sets of addresses within the meaning of the invention) capable of be shared between several client devices connected to a network.
- the two devices can be co-located or embedded in separate equipment, be deployed in the network in a distributed or centralized manner, the network being able to include several successive operator NAT levels.
- the IP addresses in 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.
- IPv6 network prefixes into other IPv6 prefixes
- no assumption is made as to the nature of client equipment likely to share the same IP address: it may be terminals, access equipment to an operator's network such as a CPE, etc.
- the invention can also be applied in other contexts, and in particular to other devices managing a plurality of IP addresses capable of being shared between several client devices, such as for example to devices implementing a proxy function using its own IP addresses to relay received data packets.
- devices are for example described in sections 5, 6 and 7 of document RFC 7620 published by the IETF and entitled “Scenarios with Host Identification Complications”, August 2015.
- the invention also applies when the addresses IP managed by the first and/or second devices are allocated at a given time to unique client equipment, that is to say to IP addresses which are not shared between several client equipment.
- 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.
- packet from client equipment we mean a packet (or equivalently a message) containing data transmitted by this client equipment and intended for a recipient entity, or conversely, transmitted by a source entity and intended to customer equipment. It should be noted that within the meaning of the invention, the packet in question can be received by the first device directly from the client equipment or pass via one or more intermediate equipment (for example via one or more operator NAT when several levels of operator NAT are deployed in cascade in the network) before being received by the first device.
- the invention proposes, to respond effectively to the detection of suspicious behavior associated with an IP address (for example suspicious activity emitted with this address as 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 (alternatively or combined), namely: modify one or more address sharing rates applied by the device (first device within the meaning of invention) managing the IP address with suspicious behavior: typically, the first device can reduce the sharing rate applied to the IP address with suspicious behavior and increase that of the other IP addresses that it manages in order to be able to assign these other IP addresses to the client equipment 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 so that it can use them to process packets from client equipment which are attached to it.
- the “nominal” set of IP addresses (first set within the meaning of the invention) which is assigned to the first device is de facto extended with new IP addresses.
- These actions aim to ensure, to the first device, the availability of “healthy” IP addresses (that is to say not deemed 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 packets from client equipment that reach it, despite the associated malicious behavior to one of the active IP addresses that the first device (CGN, for example) manages.
- These actions may, in a particular embodiment, have effect for a limited period of time, for example as long as the suspicious behavior associated with the IP address in question persists.
- These mitigation actions consist, for example, of quarantining an IP address associated with suspicious behavior, such quarantining may consist of isolating incoming traffic destined for this IP address, and/or rejecting connections sent with this address. , and/or to redirect the traffic characteristic of the connections sent with this address towards a traffic inspection module, and/or to remove this IP address from the pool of IP addresses which can be used to process packets from client equipment , etc.
- 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 delegation request of IP addresses, on the second device collaborating with the first device by responding favorably to its request.
- 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 for delegation of 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 equipment served by the first device; and a step of sending to the first device a list comprising at least one IP address of the second set delegated by said second device to the first device.
- the invention also targets 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 for delegation of 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 equipment served by the first device; and a sending module, configured to send to the first device, a list comprising at least one IP address of the second set delegated by said second device to the first device.
- 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 for delegation of 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 equipment served by the first device
- Suspicious behavior 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 may result from the IP address belonging to a blocked list, or the fact that it is associated with a low reputation level, etc. These suspicious behaviors can be detected directly (that is to say locally) by the first device, or by other entities, then responsible for notifying the first device.
- the detection step may comprise the reception of a notification emitted by an attack detection function (embedded for example in an attack mitigation system or center also designated by AMS for “Attack Mitigation System” in English) or a notification issued by an IP address reputation system.
- an attack detection function embedded for example in an attack mitigation system or center also designated by AMS for “Attack Mitigation System” in English
- Such a notification can be sent for example via a DOTS channel (for “DDoS Open Threat Signaling” in English) established between the first device and the attack detection function or the aforementioned IP address reputation system.
- DOTS is a client/server architecture, specified by the IETF, which aims to provide a signaling mechanism for detecting suspicious traffic or even a proven attack so as to implement it as quickly as possible. appropriate mitigation actions.
- the implementation of the invention can be based 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 regarding attacks where an IP address belonging to the first set is the target.
- DOTS Distributed Denial-of-Service Open Threat Signaling
- 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 delegation request of IP addresses.
- the management method may comprise a step discovery of said at least one second device.
- Such dynamic discovery of devices capable of delegating 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” in English), or by querying an NRF type network function (for “Network Repository Function” in English) in a 5G network.
- OSPF Open Shortest Path First
- NRF Network Repository Function
- 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 can 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 indifferently exploit this channel to send a delegation request. delegation.
- 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 necessary, on the definition of a new transport parameter allowing the first device and the second device to find out about their respective support of the mechanism proposed by the invention (and in particular the delegation of IP addresses).
- 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.
- the communication channel can rely on a GRE tunnel (for “Generic Routing Encapsulation” in English) or IPsec (for “IP security” in English), or rely on the IP-in-IP protocol.
- GRE tunnel for “Generic Routing Encapsulation” in English
- IPsec for “IP security” in English
- the discovery step and/or the step of establishing a communication channel with a second device can be implemented before or after the detection step.
- these steps can 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.
- the establishment of a communication channel between the first device and a second device allows the devices to exchange various information, useful for their collaboration.
- the delegation request sent by the first device may include a number and/or type of delegated IP addresses desired by the first device.
- 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 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.
- the information representative of the maximum volume of traffic transmitted by the second device can be used by the first device to use in an optimized manner the IP addresses delegated to it and to distribute the traffic passing through it as best as possible.
- 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.
- the first device can distribute all or part of the traffic passing through it and attached to distinct client equipment between several IP addresses delegated by said second distinct devices.
- This embodiment has a preferred application when, for example, one of said second devices is not able to process all 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 in insufficient capacity.
- 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.
- the management method may further comprise: a step of receiving, via a communication channel with said second device, a second data packet transmitted by an entity transmitter 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 client equipment served by the first device, a step of transmitting said data to an internal IP address allocated to said customer equipment.
- 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 an entity recipient 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.
- the collaboration method may also comprise: a step of receiving a second data packet comprising data transmitted by a transmitting entity and intended for a recipient 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 recipient IP address of said data.
- the data packets transmitted by or to the client equipment (designated client equipment data packets) to which the first device assigns an IP address delegated by said second device transit via a channel communication (possibly secure) established between the first and the second device.
- the latter does not carry out any modification of the delegated IP address in question (no translation of addresses), as long as it is an address belonging to the pool of addresses that it manages. In other words, it deactivates the address translation function that it usually applies to packets passing through it.
- these embodiments do not require modification of the routing policies implemented in the network, nor of the policies for routing the 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 synchronization. routing tables maintained by network equipment. The implementation of the invention therefore does not impact the stability of the roads 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 which reaches it.
- the management and collaboration processes are implemented by a computer.
- 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 conforming to the invention and comprising suitable instructions to the implementation of a management process as described above.
- the invention also relates to a computer program on a recording medium, this program being capable of being implemented in a computer or more generally in a second device conforming to the invention and comprising suitable instructions to the implementation of a collaboration process as described above.
- Each of these programs can use any programming language, and be in the form of source code, object code, or intermediate code between source code and object code, such as in a partially compiled form, or in any other desirable shape.
- the invention also relates to an information medium or a recording medium readable by a computer, and comprising instructions for a computer program as mentioned above.
- the information or recording medium can be any entity or device capable of storing programs.
- the medium may comprise a storage means, such as a ROM, for example a CD ROM or a microelectronic circuit ROM, or even a magnetic recording means, for example a hard disk, or a flash memory.
- the information or recording medium can be a transmissible medium such as an electrical or optical signal, which can be routed via an electrical or optical cable, by radio link, by optical link without wire or by other means.
- the program according to the invention can in particular be downloaded onto an Internet type network.
- 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 management and collaboration processes according to the invention.
- the invention also aims at a system with at least a first device according to the invention and at least a second device according to the invention, configured to process at least one request for delegation of IP addresses received of a said first device.
- Figure 1 Figure 1, already described, represents address translations carried out by access equipment to a network embedding a NAT function and an operator NAT (CGN) deployed in the network;
- CGN operator NAT
- Figure 2 represents a system according to the invention in its environment, in a particular embodiment
- 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;
- Figure 4 represents the functional modules of a first device and a second device of the system of Figure 2, conforming to the invention, in a particular embodiment;
- Figure 5 represents the main steps of a management method according to the invention as they are implemented by a first device of the system of Figure 2;
- 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 delegation request at least one IP address to a second device of the system of Figure 2;
- 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;
- 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;
- Figure 9 represents an example of a system according to the invention serving CPE type client equipment
- Figure 10 illustrates a network comprising several levels of operator NAT, each level of operator NAT including a system according to the invention.
- 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 network 2, which can be fixed or mobile.
- 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 designates an integer greater than 1.
- the IPv4 addresses of each POOL#n set assigned to a CGN#n operator NAT can be, in the embodiment described here, shared between several client devices served by the CGN#n operator NAT.
- client equipment served by an operator NAT (or equivalently here, “client equipment attached to or managed by an operator NAT”), we mean that the operator NAT is in charge of processing the data packets of this client equipment (i.e. comprising data transmitted or intended for this client equipment), and in particular the translation of the IP addresses conveyed 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).
- client equipment does not necessarily have knowledge of the NAT operator designated to serve it.
- the NAT operator CGN#n does not necessarily have explicit knowledge of the client equipment to which a packet that it must process relates and which is transported using an internal IP address (the information concerning the equipment client can however be known if a mechanism as described for example in document RFC 7785, entitled “Recommendations for Prefix Binding in the Context of Softwire Dual-Stack Lite”, February 2016, is implemented by the NAT operator). It uses the “internal” IP address used to transport this packet to it to translate it into an “external” IP address from the POOL#n set.
- the NAT operator CGN#n can select, to process packets from several distinct client devices, the same IPv4 address external among the external IPv4 addresses of the POOL#n set that it manages.
- the same sharing rate (noted here “l:x” to indicate that the same IP address can be shared between x client equipment, or more generally that the same external IP address can be shared between x internal IP addresses taking into account the previous remark) can be applied by the NAT operator CGN#n to each (external) IP address intended to be shared.
- l:x the same sharing rate
- CGN#n the same sharing rate
- 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 NAT of network 2 being able to be all of the same type or different types, co-located or deployed on separate hardware equipment, or even virtualized and hosted in cloud-type infrastructures.
- operator NATs can be deployed in a distributed manner in network 2 (with (instances of) operator NATs deployed as close as possible to client equipment) or centrally.
- the same NAT operator CGN#n of system 1 can therefore sometimes be a first device conforming to the invention, sometimes a second device conforming to the invention.
- system 1 can only integrate a subset of the operator NATs of 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 system 1, find at least one first device DI and at least one second device D2 conforming to the invention.
- the invention applies to other types of computer attacks and to other attack detection functions/systems (for example more generally to AMS centers).
- the NAT operator CGN#n is configured to use here a subscription mechanism from the DMS center such as that described in the document RFC 9244 cited above, in particular in point 8.1.1; to receive via such a DOTS channel notifications from a DMS center regarding attacks whose source is an IP address from the POOL#n set, a new extension to the mechanism described in RFC 9244 can be specified.
- the new proposed extension consists of defining a new “Uri-Query” option, called for example “source-address”, allowing the NAT operator CGN#n to indicate in a request addressed to the DMS center, the addresses of the POOL set #n for which he wishes to be notified.
- Table 1 illustrates an example of such a request including the new “source-address” option populated with the IP address “1.2.3.4”.
- the 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).
- 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 NAT operator CGN#n.
- the subscription filter designates for example all or part of the IP addresses of the POOL#n set managed by the NAT operator CGN#n.
- such a reputation system REP_SYS is adapted to evaluate a reputation level of an IP address, this reputation level reflecting the degree of confidence that can be had 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 secure its behavior is considered. 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 traffic sent with such an address as the source address).
- entities for example a network router
- the DOTS channel established between a NAT operator CGN#n and the reputation system REP_SYS thus allows the NAT operator CGN#n to obtain the reputation levels determined by the reputation system REP_SYS for the IP addresses of the set POOL#n that the NAT operator CGN#n manages.
- 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.
- modules 4 rely on or control the PROC, MEM, ROM, NVM, and COM elements of the computer 3 mentioned previously, and include here, for each NAT operator CGN#n, as illustrated in Figure 4: a module 4 detection, configured to detect suspicious behavior associated with an active IP address of the POOL#n set managed by the NAT operator CGN#n, selected by the latter to process at least one packet from client equipment served by the NAT operator CGN#n; and an execution module 5, configured to execute at least one action in reaction to the suspicious behavior detected by the detection module 4.
- the EXEC execution module 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 suspicious behavior of the POOL#n set of IP addresses that can be selected by the NAT operator CGN#n to process packets from the client equipment that it serves (this removal may only concern connections likely to be to be established in the future by client equipment, but also current connections (in other words active, as represented in the BIB table maintained by CGN#n)); o an ACT2 action consisting of adjusting at least one sharing rate of at least one IP address from the POOL#n set; and o an ACT3 action consisting of requesting a delegation of IP addresses to at least one other NAT operator CGN#j of system 1, with j*n.
- delegation we mean here that the NAT operator CGN#j agrees to assign one or more IP addresses from its POOL#j set to the NAT operator CGN#n
- the choice of action or actions executed by the execution module 5 may depend on the context (for example on the nature of the malicious behavior detected, on the number of active connections processed by the NAT operator CGN#n, on the sharing rate number of IP addresses of the POOL#n set that it manages, the severity of the attack, etc.).
- the module 5 is configured to choose, in response to suspicious behavior associated with an IP address, at least one action among the action ACT2 of adjusting at least one sharing rate and the ACT3 action requesting delegation.
- other actions can be selected by the module 5 in addition to one of these two actions, and other actions can be considered in the ACT set taken into account by the execution module 5.
- the PROG1 program also defines here three other modules of the NAT operator CGN#n as the first DI device conforming to the invention, namely: a discovery module 6, configured to discover the operator NATs of 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 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 client equipment served by the NAT operator CGN#n.
- Modules 4 to 8 are described in more detail later with reference to the steps of the management method according to the invention.
- the PROG2 program also defines here a data transmission/reception module 11.
- Modules 9 to 11 of the NAT operator CGN#n are described in more detail later with reference to the steps of the collaboration method according to the invention.
- each NAT operator CGN#n also has a module 12 for managing the set POOL#n of IP addresses which is assigned and an address translation module 13.
- a module 12 for managing the set POOL#n of IP addresses which is assigned
- an address translation module 13 Of course, other functions than address translation can be implemented by the NAT operator CGN#n (for example an ALG function, etc.), however these functions are not considered here for the sake of simplification.
- the management module 12 is in particular responsible for selecting a so-called external IP address from the POOL#n set (possibly supplemented by the IP addresses which are delegated to it if applicable) to process each packet from client equipment that it receives bearing 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 client equipment is memorized by the management module 12 in association with the internal IP address, in the BIB table maintained by the NAT operator CGN#n, and stored here in the non-volatile memory NVM of the NAT operator CGN#n.
- the management module 12 can associate the same external IP address from the POOL#n set with several distinct internal IP addresses, in accordance with a sharing rate with which it has been configured, if necessary, previously.
- the address translation module 13 is configured to process the client equipment packets received by the NAT operator CGN#n, and translate where appropriate 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 NAT operator CGN#n in accordance with the information recorded in the BIB table are known per se and are not repeated further here.
- the translation module 13 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.
- different techniques can be considered in a manner known per se. For example, the differentiation can be done on the basis of a state maintained by the NAT operator CGN#n in a local table (a port number associated with the internal IP address in the BIB table, an identifier of the equipment client, a transport protocol, etc.), or by implementing an algorithm intended for this purpose (for example for an NPTv6 type operator NAT), etc.
- 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 network 2, etc.
- 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 to be used unidirectionally (only the NAT operator who established the channel can use the channel to send a delegation request as described later) or bidirectionally (each NAT operator at one end of the channel can send a delegation request to the other NAT operator).
- these COGITARE channels are encrypted and based on the QUIC protocol, described in particular in the IETF document RFC 9000 entitled “QUIC: A UDP-Based Multiplexed and Secure Transport”, May 2021
- the COGITARE channels can 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).
- tunnels or “tunneling”.
- These channels may not be encrypted, if the NAT operator is considered a trusted entity, for example.
- a new transport parameter is defined, called for example “delegate_resources_enable”.
- This parameter is set here to 1 by a NAT operator when it is configured to implement a collaboration method according to the invention, that is to say it is capable of delegating IP addresses from the pool of addresses that it manages to another NAT operator of system 1. Note that this ability does not presume the effective availability of IP addresses to be delegated at the level of the NAT operator in question, but only its capacity, in the hypothesis where such IP addresses would be available in the pool of addresses that it manages, to delegate such IP addresses, that is to say of its capacity to implement the collaboration method according to the invention and to act as a second device according to the invention.
- a NAT operator CGN#n initializes the establishment of a COGITARE channel with another NAT operator CGN#j, j*n, it inserts in the QUIC frame that it sends the parameter “delegate_re - sources_enable » valued at 1.
- 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 process 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 can be transmitted for informative purposes, and 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 him).
- the NAT operator CGN#j with which the NAT operator CGN#n attempts to establish a COGITARE channel is not capable of collaborating with another NAT operator of system 1 and delegating 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. If applicable, the procedure for establishing a COGITARE channel is prematurely closed, and no COGITARE channel is established.
- 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 that it manages, it responds with a frame QUIC 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.
- 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 “delegate_resources_enable” parameter 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# not.
- 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.
- the values 1 and 0 proposed to enhance the “delegate_resources_enable” parameter are only given for illustrative purposes and are not limiting in themselves, other values being able to be considered to indicate whether a NAT operator is able or not to delegate IP addresses to another NAT operator.
- 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).
- the module 4 for detecting the NAT operator CGN#1 can receive a notification from the reputation system REP_SYS indicating a reputation level of the bad@IP address lower than a determined threshold, with which CGN#1 has been previously configured and below which the behavior associated with the use of the IP address is considered malicious or at least suspicious.
- the detection module 4 can receive a notification from an attack detection function from a DMS center (or more generally from 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.
- the detection module 4 is configured to proceed with the resolution of this domain name with a view to obtaining the corresponding bad@IP address.
- the detection module 4 can integrate an attack detection function and itself determine locally that the bad@IP address is associated with suspicious behavior.
- CGN#1 verifies here that the bad@IP address indeed 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 verification step E40 is optional (if it is not implemented, execution module 5 is activated upon detection by module 4 of suspicious behavior associated with the bad@IP address).
- the action or actions then executed by the execution module 5 can be selected by it depending on the context.
- the execution module 5 chooses to execute at least one action from the ACT set of actions comprising: the action ACT1 consisting of removing the bad@IP address IP addresses from the POOL#1 set that can be selected by CGN#1 to process packets from the client equipment that it serves (referred to more simply in the following as “active IP addresses”).
- the action ACT1 consisting of removing the bad@IP address IP addresses from the POOL#1 set that can be selected by CGN#1 to process packets from the client equipment that it serves (referred to more simply in the following as “active IP addresses”).
- active IP addresses active IP addresses
- 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.
- maintaining the bad@IP address to process packets characteristic of active connections can be justified when the source of an attack is internal to network 2, and/or to avoid having to migrate all client equipment served with it.
- the bad@IP address by CGN#1; the action ACT2 consisting of adjusting at least one sharing rate of at least one IP address from the POOL#1 set; for example, at least one sharing rate can be increased if the NAT operator 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 necessary from active IP addresses if the AGIT action is also executed.
- a dynamic adjustment can relate globally to the sharing rates of all the IP addresses in the POOL#1 pool (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 withdrawal), or be applied in a differentiated manner to only part of the IP addresses in the POOL#1 pool.
- 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 system 1, with j* l.
- the ACT3 action can in particular 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 value maximum, defined for example by the operator OP2, making it impossible to select the action ACT2. This is, however, only an illustrative example, and the ACT3 action can be selected by the execution module 5 in other contexts.
- 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 or the actions thus chosen (step E50). It can also, in addition to the ACT2 and/or ACT3 action, also execute the AGIT action.
- the invention is not limited to the aforementioned actions and other actions can be considered and executed alternatively by the NAT operator CGN#1 such as, for example, updating a set of the REP_SYS reputation system, marking the packets using the bad@IP address to facilitate traffic recognition and classification so that traffic sinks can be dynamically set up in network 2, etc.
- the action(s) selected by the execution module 5 can be executed by the latter during a limited period of time.
- the execution module 5 can, in accordance with the action ACT1, remove the bad@IP address from the list of IP addresses that can be selected to process messages from the client equipment that it serves for a given designated duration here by PAUSE_TIMER.
- the detection module 4 can reactivate the bad@IP address, in other words reinstate it among the IP addresses of the POOL#1 set that can be selected to process messages arriving at CGN#1.
- FIG. 6 illustrates the steps implemented by the NAT operator CGN#1 at the origin of the delegation request
- Figure 7 illustrates the steps implemented by a NAT operator of system 1 receiving and accepting this delegation request.
- delegation that is to say acting as a second device within the meaning of the invention.
- the steps illustrated in Figure 7 correspond to those of a collaboration method according to the invention. It goes without saying that although being described on the basis of an illustrative example, the steps represented in Figures 5 to 7 apply to all NAT operators of system 1 depending on the role played by each of them (first or second device according to the invention).
- COGITARE channels were established, previously during step E20, by CGN#1 with the NAT operators of system 1 discovered during step E10. Furthermore, during the establishment of these COGITARE channels, CGN#1 was informed by the operator NATs with which it 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.
- the CGN#1 execution module 5 consults the CAPA table and determines to which NAT operator of system 1 it can address its IP address delegation request ( these are 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).
- 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 address @IP, for example after execution module 5 has decided to execute action ACT3.
- the CGN#1 execution module 5 asks at least one of the operator NATs identified during step E50-1 to delegate to it at least one IP address from among the POOL set of IP addresses that he manages (step E50-2). Note that the execution module 5 can address this delegation request to all the operator NATs identified during step E50-1 or only to a part of them (it can for example choose one randomly, or according to a determined criterion, etc.). For the sake of simplification, we assume here that CGN#1 addresses its delegation request to a single NAT operator of system 1, namely to the NAT operator CGN#2 (second device within the meaning of the invention).
- the execution module 5 of CGN#1 requests a delegation of IP addresses to CGN#2 by sending it a QUIC frame, specified for the needs 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 for CGN#1, such as for example a parameter named here “requested-size” indicating a preference concerning 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 valued at 0 for IPv4 addresses and at 1 for IPv6 addresses, the absence of this parameter can be considered as equivalent to a valuation of the parameter at 0, i.e. as designating IPv4 addresses), etc.
- a parameter named here “requested-size” indicating a preference concerning the size of the IP address space to be delegated
- 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
- an IP_RESOURCE_DELEGATE frame including a “requested -size” parameter valued at 32 (bits) and not containing a “requested-af” parameter indicates a request for delegation of a single IPv4 address (the “requested-size” parameter combined with the absence of “requested-af” parameter indeed indicates a number of desired delegated IP addresses).
- the “requested-size” parameter combined with the absence of “requested-af” parameter indeed indicates a number of desired delegated IP addresses.
- other parameters can be included in the IP_RESOURCE_DELEGATE delegation request, such as for example, a desired delegation duration, etc.
- the IP_RESOURCE_DELEGATE frame is received by CGN#2, by its reception module 9, via the COGITARE channel established with CGN#1 (step F10).
- CGN#2 accepts the delegation request from CGN#1 (yes response to test step F20), it establishes an “address-list” of IP addresses comprising at least one available IP address, selected in the POOL#2 set that CGN#2 manages and which it is ready to delegate to CGN#1 (step F40).
- 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.
- CGN#2 may consider other criteria to select the addresses from the POOL#2 set that it agrees to delegate to CGN# 1: it can for example select them randomly among the unused addresses (that is to say which are not active) of the POOL#2 set, or select those which do not belong to a “block -list”, etc.
- CGN#2 may also, to establish the “address-list”, take into account the preferences of CGN#1 indicated where applicable in its delegation request (see “requested-size”, “requested-nb” parameters, “requested-af”, etc.). Alternatively, CGN#2 can be configured to ignore, when establishing the address-list, the preferences indicated by CGN#1.
- CGN#2 continues to be involved in the management of traffic intended for or issued 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 the packets that it receives intended for this delegated IP address in order to transmit them to CGN# 1, and conversely, deencapsulate the packets using this delegated IP address that it receives via the COGITARE channel established with CGN#1 to transmit them to their respective recipients.
- CGN#2 is configured not to translate the delegated IP address (unlike what it does with the IP addresses of the POOL#2 set whose use is reserved for it, i.e. '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.
- CGN#2 stores in a table named here DELEG stored for example in its non-volatile memory NVM, the IP addresses of the “address-list” delegated to CGN#1 in association with an identifier of CGN#1, for example its IP address @IP-CGN#1.
- CGN#2 then sends, through 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” thus established (step F50).
- the response from CGN#2 is an IP_RESOURCE_DELEGATE frame including the “address-list”.
- This response may also include other information, such as for example a parameter named here "validity” indicating the duration during which the IP addresses of the list "address-list” is 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” that CGN#2 can manage (taking into account the fact that it remains involved in the management of this traffic as indicated previously), etc.
- validity indicating the duration during which the IP addresses of the list "address-list” is delegated to CGN#1
- rate -limit representative of the maximum volume of traffic associated with the use of a delegated IP address from the “address-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.
- 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 has sent a delegation request to the step E50-2, in other words, in the illustrative example considered here of CGN#2 (step E50-4).
- the CGN#1 execution module 5 stores in the CGN_PEERS table, for each NAT operator having delegated IP addresses to it (that is to say in the example envisaged , for CGN#2): an identifier of the NAT operator (that is to say in the example considered, an identifier of CGN#2); the list of addresses delegated by the NAT operator (that is to say in the example considered, the “address-list”); the duration of validity of the address delegation by the NAT operator (that is to say in the example considered, the duration indicated by CGN#2 in the “validity” parameter); and the maximum volume of traffic associated with the addresses delegated by the NAT operator that can be managed by it (i.e. in the example considered, the volume indicated by CGN#2 in the “rate-limit” parameter ).
- 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 if necessary during the execution of the action ACT1) to process the packets from the client equipment that it receives (step E50-5).
- the delegated IP addresses listed in the CGN_PEERS table in addition to the IP addresses of the POOL#1 set (except those removed if necessary during the execution of the action ACT1) to process the packets from the client equipment that it receives (step E50-5).
- 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 ask CGN#2 for an extension of this validity period or to request another NAT operator of system 1 the delegation of other IP addresses and, if necessary, restore the delegated IP address(es) whose validity period has expired at CGN#2.
- CGN#1 can restore 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.
- the use by CGN#1 of a delegated IP address may be limited to a period of time defined by default (for example 24 hours), or as long as CGN# 1 needs the delegated IP address in question (for example 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 this use (for example by CGN#2 or by the operator OP2 of network 2), etc.
- 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.
- 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 distinct operator NATs of system 1.
- CGN#2 can also be configured to clip traffic associated with IP addresses delegated to CGN#1 beyond the maximum volume indicated, if this maximum volume is not respected by CGN#1.
- Figure 8 illustrates by example what has just been described, and more particularly how CGN#1 and CGN#2 process the 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.
- the packet Ml transmitted 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.
- the management module 12 selects an external IP address and, in the example considered here, an external port number, noted respectively @IP14ext and P14ext, to process the packet Ml 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 couple (@IP14, P14) with the couple (@IP14ext, P14ext). For the sake of simplification here, we assume that the address @IP14ext is associated in the BIB table only with the internal IP address @IP14.
- the management module 12 extracts the external IP address and port number (@IP14ext, P14ext) entered for this entry in the BIB table.
- CGN#1 then translates the internal IP address @IP14 and the port number P14 of the packet Ml into the external IP address @IP14ext and the port number P14ext (that is to say it replaces in the header of the packet @IP14 and P14 by @IP14ext and P14ext respectively), resulting in a modified packet Ml'. It should be noted that as previously discussed, further modifications may be made by CGN#1 to the Ml package. However, for the sake of simplification here, such modifications are not described further here.
- a QUIC M2 packet also commonly referred to as a QUIC M2 frame
- the port number used can be a port number chosen randomly when establishing the COGITARE channel with CGN#2, as described for example in the RFC 6056 document 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 does not matter.
- CGN#2 On receipt of the M2 frame, CGN#2 checks, using its DELEG table, whether the source IP address (that is to say here the address @IP-CGN#1) corresponds to an IP address from its POOL#2 set delegated to CGN#1, the M2 frame being received via the COGITARE channel established with CGN#1.
- source IP address that is to say here the address @IP-CGN#1
- CGN#2 deletes frame M2.
- CGN#2 decapsulates the packet Ml' from the frame M2 then transmits the packet Ml' to its recipient, that is to say towards the server S, without carrying out any translation of addresses on the Ml' packet.
- the server S responds to the client equipment 14 by sending it an M3 packet containing data.
- the M3 packet being intended for an IP address of the POOL#2 set managed by the CGN#2, it is, in the embodiment described here, sent to CGN#2.
- CGN#2 On receipt of the M3 packet, CGN#2 checks whether the recipient 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 the system 1. He uses his DELEG table for this purpose.
- 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.
- 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 within the meaning of the invention) without modifying the IP address recipient (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, via its transmission/reception module 11, the M4 frame to CGN#1, via the COGITARE channel established between the two operator NATs.
- the M4 frame contains the M3 packet (in particular the data transmitted 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 the CGN# 2, and as the recipient IP address, the IP address @IP-CGN#1 of CGN#1.
- source IP address the IP address @IP-CGN#2 of the CGN# 2
- recipient IP address the IP address @IP-CGN#1 of CGN#1.
- CGN#1 On receipt of the M4 frame, CGN#1 verifies that the source IP address @IP-CGN#2 of the M4 frame corresponds to an entry in its CGN_PEERS table. If this is not the case, the M4 frame is deleted.
- CGN#1 extracts the M3 packet from the M4 frame. Then it checks in its BIB table if an entry corresponding to the recipient IP address of the M3 packet (that is to say here the external IP address @IP14ext) exists.
- CGN#1 deletes the M3 packet.
- the client equipment of network 2 are terminals communicating directly with the operator NATs of system 1.
- the invention can consider applying the invention to other types of client equipment of network 2 and in particular to access equipment to network 2 such as CPEs connecting for example terminals connected to a local network (LAN) to network 2.
- the invention is applied in an identical manner to what has just been described for terminal type client equipment at the level of a CPE.
- 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 access equipment to network 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 has been described with reference to Figure 8 for the terminal 14.
- the packet Ml however results from a modification by the CPE 14 of a packet Ml_0 transmitted by the terminal 16 containing data intended for the server S, this packet Ml_0 having as source IP address and port number, an internal IP address and port number noted respectively @IP16 and P16, allocated by the CPE 14 at the terminal 16.
- the modification made by the CPE 14 on the packet Ml_0, resulting in the packet Ml consists of replacing in the header of the packet Ml_0 the internal IP address @IP16 and the port number P16 by the IP address @IP14 and the port number P14 allocated to the CPE 14.
- the opposite modification is applied by the CPE 14 to the packet M3' resulting in a packet M3" then sent to the terminal 16.
- system 1 is configured so that when a NAT operator CGN#j of system 1 delegates one or more IP addresses to a NAT operator CGN#k, with k*j, CGN#j continues to receive traffic associated with these delegated IP addresses.
- the routing tables maintained by the routers of 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 customer equipment it serves.
- the tables of 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), during the delegation.
- each NAT operator of 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 .
- each NAT operator CGNi#p of the system 1-i 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 NAT operator CGNi#t, with t*p , belonging to the same 1-i system and therefore at the same LEVi level as it.
- COGITARE channels (represented by double arrows in Figure 10) can thus be established between NAT operators of the same level.
- Figure 10 illustrates different situations experienced by systems 1-1 and 1-2 in network 2'.
- Figure 10a illustrates the state of the network 2' and the systems 1-1 and 1-2 in a normal state (nominal conditions).
- Each packet from client equipment passes successively in the 2' network through two operator NATs belonging respectively to the LEVI level and the LEV2 level.
- Each NAT operator selects an IP address in the POOL IP address space assigned to it to process this packet.
- a message associated with a terminal 17 passes through the NAT operator CGN1#1 in system 1-1 and through the NAT operator CGN2#2 in system 1-2.
- Figure 10b illustrates a situation in which the module 4 for detecting a CGNl#m of 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.
- CGN1#1 selects one of the IP addresses delegated by CGN1#2 to process the packets associated with the terminal 17.
- the packets sent by the server 18 containing data intended for the terminal 17 follow the reverse path : they pass through CGN2#2 which carries out 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 carrying out an address translation.
- CGN1#1 after replacing the delegated external IP address used for the packets by an internal IP address allocated to terminal 17, sends these packets to terminal 17.
- 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 the system 1-i is detected, triggering a delegation request of IP addresses and a delegation of IP addresses at each level.
- 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 the system 1-2 are detected, resulting in a delegation of IP addresses by CGN1#1 to CGN1#I and a delegation of IP addresses by CGN2#J to CGN2#2.
- the invention is not limited to two levels of operator NAT deployed in the network, a larger number of NAT levels can be considered, the invention applying in the same way as that which has been described previously with reference to Figures 2 to 9 independently at each level.
- the invention has been described with reference to NAT operators.
- the invention can be applied to other devices managing a plurality of IP addresses capable of being shared between several client devices, such as for example to devices implementing a proxy function using its own IP addresses to relay messages received.
- Such devices are for example described in sections 5, 6 and 7 of the document RFC 7620 mentioned previously.
- the invention also applies when the IP addresses managed by the first and/or second devices are not shared between several client devices.
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Computer Security & Cryptography (AREA)
- Computer Hardware Design (AREA)
- Computing Systems (AREA)
- General Engineering & Computer Science (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
Abstract
Le procédé de gestion comprend : - une détection d'un comportement suspect associé à une adresse IP d'un premier ensemble d'adresses IP sélectionnée par un premier dispositif (CGN#1) d'un réseau pour traiter au moins un paquet d'un équipement client servi par le premier dispositif; - une exécution d'au moins une action parmi: - un ajustement d'au moins un taux de partage d'au moins une adresse IP du premier ensemble appliqué par le premier dispositif; - une demande à au moins un deuxième dispositif (CGN#2) gérant un deuxième ensemble d'adresses IP de délégation d'au moins une adresse IP du deuxième ensemble au premier dispositif pour qu'il puisse sélectionner cette adresse IP déléguée pour traiter au moins un paquet d'au moins un équipement client servi par le premier dispositif.
Description
Description
Titre de l'invention : Procédé de gestion d'un ensemble d'adresses IP, procédé de collaboration et dispositifs configurés pour mettre en œuvre ces procédés.
Technique antérieure
[0001] L'invention appartient au domaine général des télécommunications.
[0002] Elle concerne la gestion d'un service de connectivité, plus particulièrement en cas d'attaques informatiques dans un réseau de télécommunications, telles que par exemple des attaques par déni de service (ou DDoS pour « Distributed Denial of Service » en anglais).
[0003] De façon connue en soi, une attaque DDoS est une tentative de rendre des ressources (par exemple des ressources de calcul ou des ressources réseau) indisponibles pour leurs utilisateurs. De telles attaques peuvent être massives et de nature à compromettre plusieurs centaines de milliers d'équipements clients (par exemple des terminaux), qui peuvent à leur tour être utilisés comme relais pour amplifier le pouvoir de nuisance des attaques. Ces attaques sont de plus en plus fréquentes et intenses ; leur ampleur en termes de durée mais aussi d'étendue et de propagation rend difficile la tâche du ou des services DPS (pour « DDoS Protection Service » en anglais) déployés dans le réseau pour détecter et mitiger de telles attaques (par exemple via une mise en quarantaine des ressources ciblées par les attaques, de filtrage du trafic associé à une attaque, etc.).
[0004] En outre, la mise en place d'actions de mitigation au sein d'un réseau est particulièrement problématique en présence de dispositifs de translation d'adresses aussi appelés NAT (pour « Network Address Translation » en anglais) opérateurs (ou encore CGN pour « Carrier Grade NAT » en anglais, ou LSN pour « Large Scale NAT » en anglais).
[0005] Un NAT opérateur est un dispositif mettant en œuvre une fonction de translation (aussi appelée traduction) d'adresses IP (et le cas échéant, de numéros de port) dans un réseau d'opérateur. Plusieurs types de NAT opérateur ont été spécifiés par l'IETF (pour « Internet Engineering Task Force » en anglais) et déployés par les opérateurs (par exemple NAT 4, NAT64, DS-Lite, NPTv6, etc.). Par exemple, dans une architecture dite de double NAT, la fonction NAT d'un CGN vient s'ajouter à la fonction NAT embarquée dans l'équipement client d'accès au réseau (par exemple dans un CPE pour « Customer Premises Equipment » en anglais). Les architectures réseaux reposant sur l'exploitation de CGN permettent notamment de mettre en place un mécanisme de partage d'adresses IP, offrant par exemple une solution de continuité de service dans un contexte de pénurie d'adresses IPv4.
[0006] Par exemple, une adresse dite « interne » (par exemple une adresse privée dans le cas d'une ingénierie double NAT) est affectée en lieu et place d'une autre adresse, dite « externe » (par exemple une adresse globale IPv4 dans le cas d'un ingénierie double NAT, notamment) à l'interface de raccordement de l'équipement d'accès (par exemple un CPE) du client au réseau. La translation de l'adresse interne affectée à l'interface de raccordement de l'équipement d'accès en une adresse externe est effectuée par le NAT opérateur (CGN). La figure 1 illustre, sur un exemple, les différentes translations d'adresses effectuées respectivement par un équipement d'accès CPE1 et par un NAT
opérateur CGN2 sur des paquets de données IP émis par un terminal H3, connecté par exemple à un réseau d'entreprise ou un réseau domestique, et destiné à un équipement distant S4.
[0007] Ainsi, dans l'exemple de la figure 1, un paquet P de données IP ayant pour adresse IP source 10.2.25.5 et un numéro de port source 12345 est émis par le terminal H, et reçu par l'équipement d'accès CPE1. On suppose ici que l'adresse IP privée 192.168.1.56 et le numéro de port 16587 sont affectés à l'interface WAN (pour « Wide Area Network » en anglais) de l'équipement d'accès CPE1 dans le cas d'une ingénierie double NAT. La fonction NAT de l'équipement d'accès CPE1 remplace alors dans l'entête du paquet P de données IP reçu du terminal H3, le couple (10.2.25.5,12345) par le couple (192.168.1.56,16587). Il peut également procéder à d'autres modifications, comme par exemple l'exécution d'un code de redondance cyclique (CRC, plus couramment désigné par « checksum » en anglais) ou l'application d'une fonction de type ALG (pour « Application Level Gateway » en anglais). Puis l'équipement d'accès CPE1 envoie le paquet P' de données IP dont au moins le champ adresse source a été modifié après exécution de la fonction NAT vers un NAT opérateur CGN2. Sur réception du paquet P' de données IP, le NAT opérateur CGN2 sélectionne une adresse IP externe (par exemple une adresse IPv4 publique) et un numéro de port externe (par exemple un numéro de port public) pour le traitement du paquet P', par exemple le couple (1.2.3.4, 45875), et associe dans une base d'informations, par exemple une base BIB (pour « Binding Information Base ») le couple (1.2.3.4, 45875) au couple (192.168.1.56, 16587) ainsi que le protocole de transport utilisé (non mentionné dans la figure 1 par souci de simplification). Puis le NAT opérateur CGN2 remplace dans l'entête du paquet P' de données IP, l'adresse IP interne 192.168.1.56 et le numéro de port interne 16587, par l'adresse IP externe 1.2.3.4 et le numéro de port externe 45875 respectivement. Le paquet P" de données IP ainsi obtenu est ensuite transféré par le NAT opérateur CGN2 vers sa destination (l'équipement distant S4 de la figure).
[0008] On note que la pénurie d'adresses IPv4 est un problème également rencontré dans les réseaux mobiles, en raison de la limitation de l'espace d'adressage privé (18 millions d'adresses disponibles au total). En effet, les ingénieries actuelles de réseaux mobiles ont tendance à affecter quasiment systématiquement une adresse IPv4 privée à chaque terminal mobile. Les opérateurs qui mettent en œuvre de telles ingénieries doivent donc également mettre en place des mécanismes de partage d'adresses IPv4 privées reposant sur des NAT opérateur (CGN) déployés typiquement au niveau de l'interface Gi (sGi ou N6 selon la release 3GPP considérée) permettant de raccorder un réseau d'accès mobile au réseau de données (par exemple, Internet). En outre, des mécanismes de conversion de type NAT64 peuvent également être déployés dans les réseaux des opérateurs qui ont défini une stratégie de migration vers IPv6, protocole dont l'espace d'adressage est présenté comme la solution durable à la pénurie d'adresses IPv4. Un tel mécanisme de translation d'adresses NAT64 permet avantageusement à un nœud dit IPv6-only supportant uniquement le protocole IPv6 de communiquer avec un nœud dit IPv4-only supportant uniquement le protocole IPv4, en convertissant les paquets de données IPv6 reçus du nœud IPv6-only en des paquets IPv4 avant de les transmettre au nœud IPv4-only.
[0009] Le document RFC 6269 publié par l'IETF liste un ensemble de problèmes inhérents aux solutions de partage d'adresses. Typiquement, dans un contexte de mitigation d'attaques, la mise en quarantaine d'une adresse IP associée à une attaque DDoS impacte
tous les équipements clients partageant cette adresse. La mise en place d'actions de mitigation dans un réseau ou par un serveur distant risque ainsi d'impacter la qualité de service perçue par tous les équipements clients qui partagent une même adresse IP, voire rendre le service indisponible pour certains.
Exposé de l'invention
[0010] L'invention permet notamment d'améliorer l'efficacité des politiques de mitigation d'attaques dans des environnements réseaux où des fonctions qui agrègent plusieurs connexions en utilisant des adresses susceptibles d'être partagées (par exemple des fonctions CGN ou proxy) sont déployées, en proposant un procédé de gestion, par un premier dispositif localisé dans un réseau, d'un premier ensemble d'adresses IP, ce procédé comprenant : une étape de détection d'un comportement suspect associé à une adresse IP du premier ensemble sélectionnée par le premier dispositif pour traiter au moins un paquet de données d'un équipement client servi par le premier dispositif ; suite à ladite détection, une étape d'exécution d'au moins une action parmi : o un ajustement d'au moins un taux de partage d'au moins une adresse IP du premier ensemble appliqué par le premier dispositif ; et o une demande, adressée à au moins un deuxième dispositif gérant un deuxième ensemble d'adresses IP, de délégation d'au moins une adresse IP du deuxième ensemble au premier dispositif pour que le premier dispositif puisse sélectionner ladite au moins une adresse IP déléguée pour traiter au moins un paquet de données d'au moins un équipement client servi par le premier dispositif.
[0011] Corrélativement, l'invention concerne également un dispositif, dit premier dispositif, localisé dans un réseau, ce premier dispositif gérant un premier ensemble d'adresses IP et comprenant : un module de détection, configuré pour détecter un comportement suspect associé à une adresse IP dudit premier ensemble sélectionnée par le premier dispositif pour traiter au moins un paquet de données d'un équipement client servi par le premier dispositif ; un module d'exécution, configuré pour exécuter suite à ladite détection, au moins une action parmi : o un ajustement d'au moins un taux de partage d'au moins une adresse IP du premier ensemble appliqué par le premier dispositif ; et o une demande, adressée à au moins un deuxième dispositif gérant un deuxième ensemble d'adresses IP, de délégation d'au moins une adresse IP du deuxième ensemble au premier dispositif pour que le premier dispositif puisse sélectionner ladite au moins une adresse IP déléguée pour traiter au moins un paquet de données d'au moins un équipement client servi par le premier dispositif.
[0012] Les premier et deuxième dispositifs peuvent être typiquement des NAT opérateur (ou CGN ou encore LSN) tels que décrits précédemment, configurés pour gérer des pools d'adresses IP distincts (ensembles d'adresses au sens de l'invention) susceptibles d'être partagées entre plusieurs équipements clients connectés à un réseau. Les deux dispositifs peuvent être colocalisés ou être embarqués dans des équipements distincts, être
déployés dans le réseau de façon distribuée ou centralisée, le réseau pouvant comprendre plusieurs niveaux de NAT opérateur se succédant. Les adresses IP d'un même pool peuvent être des adresses IPv4 et/ou des adresses IPv6, contiguës ou non. L'invention s'applique à tout type de NAT opérateur (par exemple, NAT44, NAT64, DS-lite, NPTv6 (c'est-à-dire mettant en œuvre une traduction de préfixes réseau IPv6 en d'autres préfixes IPv6), etc.). Par ailleurs, aucune hypothèse n'est faite quant à la nature des équipements clients susceptibles de partager une même adresse IP : il peut s'agir de terminaux, d'équipements d'accès au réseau d'un opérateur tels qu'un CPE, etc.
[0013] L'invention peut également s'appliquer dans d'autres contextes, et notamment à d'autres dispositifs gérant une pluralité d'adresses IP susceptibles d'être partagées entre plusieurs équipements clients, comme par exemple à des dispositifs mettant en œuvre une fonction proxy utilisant ses propres adresses IP pour relayer des paquets de données reçus. De tels dispositifs sont par exemple décrits dans les sections 5, 6 et 7 du document RFC 7620 publié par l'IETF et intitulé « Scenarios with Host Identification Complications », août 2015. En outre, l'invention s'applique également lorsque les adresses IP gérées par les premier et/ou deuxième dispositifs sont allouées à un instant donné à des équipements clients uniques, c'est-à-dire à des adresses IP qui ne sont pas partagées entre plusieurs équipements clients.
[0014] Les adresses IP gérées par les premier et deuxième dispositifs, ainsi que les adresses IP déléguées, sont utilisées par lesdits dispositifs pour traiter des paquets de données d'équipements clients. Par « paquet d'un équipement client », on entend un paquet (ou de façon équivalente un message) contenant des données émises par cet équipement client et destinées à une entité destinataire, ou à l'inverse, émises par une entité source et destinées à l'équipement client. Il convient de noter qu'au sens de l'invention, le paquet en question peut être reçu par le premier dispositif directement de l'équipement client ou transiter via un ou plusieurs équipements intermédiaires (par exemple via un ou plusieurs NAT opérateur lorsque plusieurs niveaux de NAT opérateur sont déployés en cascade dans le réseau) avant d'être reçu par le premier dispositif.
[0015] Ainsi, l'invention propose, pour répondre efficacement à la détection d'un comportement suspect associé à une adresse IP (par exemple activité suspecte émise avec cette adresse comme adresse source) dans un réseau dans lequel les adresses IP sont susceptibles d'être partagées entre plusieurs équipements clients, de mettre en place deux types d'actions (de façon alternative ou combinée), à savoir : modifier un ou plusieurs taux de partage d'adresses appliqués par le dispositif (premier dispositif au sens de l'invention) gérant l'adresse IP au comportement suspect : typiquement, le premier dispositif peut réduire le taux de partage appliqué à l'adresse IP au comportement suspect et augmenter celui des autres adresses IP qu'il gère afin d'être en mesure d'attribuer ces autres adresses IP aux équipements clients qu'il sert (actuels et futurs) ; bénéficier de l'assistance d'un autre dispositif (deuxième dispositif au sens de l'invention), et notamment lui demander de lui déléguer une ou plusieurs adresses IP « saines » afin qu'il puisse les utiliser pour traiter les paquets des équipements clients qui lui sont rattachés. De la sorte, on étend de facto avec de nouvelles adresses IP l'ensemble « nominal » des adresses IP (premier ensemble au sens de l'invention) qui est affecté au premier dispositif.
[0016] Ces actions ont pour but d'assurer au premier dispositif, la disponibilité d'adresses IP « saines » (c'est-à-dire non réputées pour avoir été utilisées à des fins frauduleuses et
qui ne sont donc pas a priori visées en tant que cibles ou utilisées par la source d'une attaque) pour qu'il soit en mesure de traiter les paquets d'équipements clients qui lui parviennent, et ce, en dépit du comportement malveillant associé à l'une des adresses IP actives que le premier dispositif (CGN, par exemple) gère. Ces actions peuvent, dans un mode de réalisation particulier, avoir un effet pendant une période de temps limitée, par exemple tant que le comportement suspect associé à l'adresse IP en question subsiste.
[0017] Grâce à l'exécution de telles actions, l'impact des attaques informatiques sur le fonctionnement du ou des services souscrits par les utilisateurs des équipements clients qui éventuellement partagent une même adresse IP, est réduit. Il convient de noter que le partage d'adresses IP est souvent réalisé dans le réseau à l'insu des utilisateurs. Par exemple, comme évoqué précédemment, il peut être mis en place par un opérateur d'un réseau pour pallier la pénurie d'adresses IPv4. L'invention permet de faire en sorte que ce partage d'adresses IP reste transparent pour les utilisateurs et n'impacte pas la qualité de service expérimentée par ces derniers. L'opérateur peut en effet grâce à l'invention garantir une continuité de service aux utilisateurs tout en assurant l'efficacité des actions de mitigation mises en œuvre pour répondre à un comportement suspect détecté dans le réseau. Ces actions de mitigation consistent par exemple à mettre en quarantaine une adresse IP associée à un comportement suspect, une telle mise en quarantaine pouvant consister à isoler le trafic entrant à destination de cette adresse IP, et/ou à rejeter des connexions émises avec cette adresse, et/ou à rediriger le trafic caractéristique des connexions émises avec cette adresse vers un module d'inspection de trafic, et/ou à retirer cette adresse IP du pool d'adresses IP pouvant être utilisées pour traiter les paquets d'un équipement client, etc.
[0018] Ainsi, comme il apparaît au vu de ce qui précède, l'invention repose sur le premier dispositif déclenchant une action en réponse à un comportement suspect associé à une adresse IP partagée, mais également, lorsque cette action comprend une demande de délégation d'adresses IP, sur le deuxième dispositif collaborant avec le premier dispositif en répondant favorablement à sa demande.
[0019] L'invention concerne donc également, selon un autre aspect, un procédé de collaboration avec un premier dispositif localisé dans un réseau et gérant un premier ensemble d'adresses IP comprenant une adresse IP associée à un comportement suspect, ledit procédé étant destiné à être mis en œuvre par un deuxième dispositif gérant un deuxième ensemble d'adresses IP et comprenant : une étape de réception, en provenance du premier dispositif, d'une demande de délégation d'au moins une adresse IP du deuxième ensemble au premier dispositif pour que le premier dispositif puisse sélectionner ladite au moins une adresse IP déléguée pour traiter au moins un paquet de données d'au moins un équipement client servi par le premier dispositif ; et une étape d'envoi au premier dispositif d'une liste comprenant au moins une adresse IP du deuxième ensemble déléguée par ledit deuxième dispositif au premier dispositif.
[0020] Corrélativement, l'invention vise aussi un dispositif, dit deuxième dispositif, localisé dans un réseau, ledit deuxième dispositif gérant un deuxième ensemble d'adresses IP et comprenant : un module de réception, configuré pour recevoir, en provenance d'un premier dis-
positif gérant un premier ensemble d'adresses IP comprenant une adresse IP associée à un comportement suspect, une demande de délégation d'au moins une adresse IP du deuxième ensemble au premier dispositif pour que le premier dispositif puisse sélectionner ladite au moins une adresse IP déléguée pour traiter au moins un paquet de données d'au moins un équipement client servi par le premier dispositif ; et un module d'envoi, configuré pour envoyer au premier dispositif, une liste comprenant au moins une adresse IP du deuxième ensemble déléguée par ledit deuxième dispositif au premier dispositif.
[0021] Les avantages du procédé de collaboration et du deuxième dispositif sont similaires à ceux décrits précédemment pour le procédé de gestion et le premier dispositif.
[0022] Les comportements suspects associés à des adresses IP pouvant déclencher l'exécution d'un ajustement d'un taux de partage d'adresses IP ou d'une demande de délégation conformément à l'invention peuvent être de différentes natures ; par exemple le comportement suspect détecté peut résulter de l'appartenance de l'adresse IP à une liste bloquée (ou « block-list » en anglais), ou le fait qu'elle soit associée à un niveau de réputation faible, etc. Ces comportements suspects peuvent être détectés directement (c'est-à-dire localement) par le premier dispositif, ou par d'autres entités, chargées alors de notifier le premier dispositif.
[0023] Ainsi, dans un mode particulier de réalisation, l'étape de détection peut comprendre la réception d'une notification émise par une fonction de détection d'attaques (embarquée par exemple dans un système ou centre de mitigation d'attaques aussi désigné par AMS pour « Attack Mitigation System » en anglais) ou d'une notification émise par un système de réputation d'adresses IP.
[0024] Une telle notification peut être émise par exemple via un canal DOTS (pour « DDoS Open Threat Signaling » en anglais) établi entre le premier dispositif et la fonction de détection d'attaques ou le système de réputation d'adresses IP précités. De façon connue en soi, DOTS est une architecture client/serveur, spécifiée par l'IETF, qui a pour objectif de fournir un mécanisme de signalisation de détection de trafic suspect voire d'attaque avérée de sorte à mettre en œuvre le plus rapidement possible des actions de mitigation appropriées. Ainsi, la mise en œuvre de l'invention peut s'appuyer notamment sur l'implémentation par le premier dispositif du mécanisme décrit dans le document RFC 9244 de l'IETF intitulé « Distributed Denial-of-Service Open Threat Signaling (DOTS) Telemetry », juin 2022, pour recevoir des notifications concernant des attaques dont une adresse IP appartenant au premier ensemble est la cible. Pour les attaques dont la source est une adresse IP du premier ensemble, on peut envisager de spécifier une extension de ce mécanisme de signalisation DOTS consistant à définir une nouvelle option « Uri-Query » appelée par exemple « source-address », valorisée avec l'adresse IP en question, comme détaillé davantage ultérieurement.
[0025] Bien entendu, ceci n'est qu'un exemple illustratif d'implémentation de l'invention, et d'autres mécanismes de notification du premier dispositif peuvent être envisagés.
[0026] Comme évoqué précédemment, l'invention s'applique dans différents contextes.
[0027] Ainsi, dans un mode de réalisation particulier, on peut envisager que le premier dispositif soit configuré avec une liste de deuxièmes dispositifs selon l'invention avec lesquels il peut envisager de collaborer et plus particulièrement, auxquels il peut envoyer une demande de délégation d'adresses IP.
[0028] Dans un autre mode de réalisation, le procédé de gestion peut comprendre une étape
de découverte dudit au moins un deuxième dispositif.
[0029] Une telle découverte dynamique des dispositifs susceptibles de lui déléguer des adresses IP peut être mise en œuvre par le premier dispositif par exemple en utilisant un protocole de routage dynamique tel que OSPF (pour « Open Shortest Path First » en anglais), ou en interrogeant une fonction réseau de type NRF (pour « Network Repository Function » en anglais) dans un réseau 5G.
[0030] Dans un mode particulier de réalisation, le procédé de gestion peut comprendre en outre une étape d'établissement avec ledit au moins un deuxième dispositif d'au moins un canal de communication, par exemple un canal de communication chiffré. Ce canal de communication peut être établi de sorte à être utilisé de façon unidirectionnelle par le premier dispositif pour envoyer une demande de délégation au deuxième dispositif, ou de façon bidirectionnelle, chacun des premier et deuxième dispositifs pouvant indifféremment exploiter ce canal pour envoyer une demande de délégation.
[0031] Le canal de communication établi entre le premier dispositif et un dit deuxième dispositif peut être notamment un canal de communication chiffré reposant par exemple sur le protocole QUIC, et éventuellement le cas échéant, sur la définition d'un nouveau paramètre de transport permettant au premier dispositif et au deuxième dispositif de s'informer sur leur support respectif du mécanisme proposé par l'invention (et en particulier de la délégation d'adresses IP).
[0032] Le protocole QUIC permet avantageusement d'établir un canal de communication chiffré donc sécurisé entre les deux dispositifs ; conformément au protocole QUIC, non seulement les données utiles échangées par les premier et deuxième dispositifs sont chiffrées mais également la plupart des données de contrôle, ce qui apporte une protection supplémentaire contre d'éventuelles attaques. Il s'agit toutefois d'un simple exemple d'implémentation de l'invention, et d'autres mécanismes peuvent être envisagés. Par exemple, le canal de communication peut s'appuyer sur un tunnel GRE (pour « Generic Routing Encapsulation » en anglais) ou IPsec (pour « IP security » en anglais), ou reposer sur le protocole IP-in-IP. Il convient de noter que l'établissement d'un canal de communication chiffré permet avantageusement de renforcer la sécurité du mécanisme proposé, notamment si un dispositif (ou nœud) du réseau est compromis. Il est toutefois possible de s'affranchir d'un tel chiffrement si on considère que tous les dispositifs du réseau sont de confiance.
[0033] L'étape de découverte et/ou l'étape d'établissement d'un canal de communication avec un deuxième dispositif peu(ven)t être mise(s) en œuvre avant ou après l'étape de détection. En d'autres termes, ces étapes peuvent être déclenchées par la détection d'un comportement suspect associé à une adresse IP, de sorte à réduire notamment les ressources monopolisées pour la mise en œuvre de l'invention, ou être réalisées préalablement, indépendamment de toute détection d'un comportement suspect associé à une adresse IP gérée par le premier dispositif, de sorte à réduire le temps de réaction du premier dispositif face à un comportement suspect associé à une adresse IP qu'il gère.
[0034] L'établissement d'un canal de communication entre le premier dispositif et un deuxième dispositif permet aux dispositifs d'échanger diverses informations, utiles à leur collaboration.
[0035] Ainsi, dans un mode particulier de réalisation, la demande de délégation adressée par le premier dispositif peut comprendre un nombre et/ou un type d'adresses IP déléguées souhaités par le premier dispositif.
[0036] Dans un autre mode de réalisation, le procédé de gestion comprend en outre une étape de réception par le premier dispositif, en réponse à une dite demande de délégation adressée par le premier dispositif à un dit deuxième dispositif, au moins un élément parmi : une liste comprenant au moins une adresse IP déléguée par ce deuxième dispositif au premier dispositif ; une durée pendant laquelle ladite liste est déléguée au premier dispositif ; une information représentative d'un volume maximum de trafic, associé à l'usage d'une adresse IP déléguée par ledit au moins un deuxième dispositif au premier dispositif et pouvant être géré par le deuxième dispositif.
[0037] Ces diverses informations permettent de rendre la collaboration entre les deux dispositifs plus efficace, et mieux adaptée aux besoins du premier dispositif et/ou aux capacités du deuxième dispositif. Elles ne sont pas limitatives en soi, et d'autres informations peuvent être échangées entre les dispositifs.
[0038] L'information représentative du volume maximum de trafic transmise par le deuxième dispositif peut être exploitée par le premier dispositif pour utiliser de façon optimisée les adresses IP qui lui sont déléguées et répartir au mieux le trafic transitant par lui.
[0039] Par exemple, dans un mode particulier de réalisation, le procédé de gestion comprend une étape de sélection d'au moins deux adresses IP déléguées par desdits deuxièmes dispositifs distincts pour traiter des paquets d'au moins deux équipements clients distincts servis par le premier dispositif.
[0040] Ainsi, dans ce mode de réalisation, le premier dispositif peut répartir tout ou partie du trafic transitant par lui et rattaché à des équipements clients distincts entre plusieurs adresses IP déléguées par desdits deuxièmes dispositifs distincts. Ce mode de réalisation a une application privilégiée lorsque par exemple l'un desdits deuxièmes dispositifs n'est pas en mesure de traiter tout le trafic en question. Le premier dispositif peut alors faire appel à d'autres dispositifs pour traiter l'excédent de trafic par rapport au volume de trafic maximum indiqué par ledit deuxième dispositif en capacité insuffisante.
[0041] Dans un mode particulier de réalisation, le procédé de gestion comprend en outre : une étape de réception, depuis une adresse IP source interne, d'un premier paquet de données comprenant des données destinées à une entité destinataire ; une étape de remplacement de cette adresse IP source interne par une dite adresse IP déléguée par un dit deuxième dispositif au premier dispositif et sélectionnée par le premier dispositif pour traiter le premier paquet de données ; et une étape de transmission des données avec l'adresse IP déléguée audit deuxième dispositif, via un canal de communication établi avec lui, pour que lesdites données soient acheminées vers l'entité destinataire.
[0042] De façon similaire, dans un mode particulier de réalisation, le procédé de gestion peut en outre comprendre : une étape de réception, via un canal de communication avec un dit deuxième dispositif, d'un deuxième paquet de données émis par une entité émettrice et comprenant des données destinées à une adresse IP du deuxième ensemble d'adresses IP géré par le deuxième dispositif ; et si ladite adresse IP est déléguée au premier dispositif par le deuxième dispositif et sélectionnée par le premier dispositif pour traiter des paquets de données d'un équipement client servi par le premier dispositif, une étape de transmission desdites données vers une adresse IP interne allouée audit équipement client.
[0043] Corrélativement, dans un mode particulier de réalisation, le procédé de collaboration comprend en outre : une étape de réception, via un canal de communication établi avec le premier dispositif, d'un premier paquet de données comprenant des données destinées à une entité destinataire et émis avec une adresse IP source appartenant au deuxième ensemble d'adresses IP géré par le deuxième dispositif ; et si ladite adresse IP source est une dite adresse IP déléguée par le deuxième dispositif au premier dispositif, une étape de transmission desdites données vers l'entité destinataire sans modifier ladite adresse IP source desdites données.
[0044] Par ailleurs, dans un autre mode de réalisation, le procédé de collaboration peut également comprendre : une étape de réception d'un deuxième paquet de données comprenant des données émises par une entité émettrice et destinées à une adresse IP destinataire appartenant au deuxième ensemble d'adresses IP géré par le deuxième dispositif ; et si ladite adresse IP est une dite adresse IP déléguée par le deuxième dispositif au premier dispositif, une étape de transmission desdites données au premier dispositif via le canal de communication établi avec ledit premier dispositif sans modifier ladite adresse IP destinataire desdites données.
[0045] Ces modes de réalisation du procédé de gestion et du procédé de collaboration ont une application privilégiée lorsque les premier et deuxième dispositif en question sont des NAT opérateur. Dans ces modes de réalisation, les paquets de données émis par ou à destination de l'équipement client (désignés par paquets de données de l'équipement client) auxquels le premier dispositif attribue une adresse IP déléguée par un dit deuxième dispositif transitent via un canal de communication (éventuellement sécurisé) établi entre le premier et le deuxième dispositif. Il convient de noter que lorsque les paquets de données associés à une adresse IP déléguée par le deuxième dispositif au premier dispositif parviennent au deuxième dispositif, celui-ci n'effectue aucune modification de l'adresse IP déléguée en question (pas de translation d'adresses), dès lors qu'il s'agit d'une adresse appartenant au pool d'adresses qu'il gère. Autrement dit, il désactive la fonction de translation d'adresses qu'il applique habituellement sur les paquets qui transitent par lui.
[0046] Avantageusement, ces modes de réalisation ne requièrent pas de modification des politiques de routage mises en place dans le réseau, ni des politiques d'acheminement du trafic transitant par les premier et deuxième dispositifs. En effet, ces modes de réalisation ne nécessitent pas de synchronisation des tables de routage des équipements du réseau liée à la délégation d'adresses IP, et par conséquent, permettent de s'affranchir de l'impact des temps de convergence associés à la synchronisation des tables de routage maintenues par les équipements du réseau. La mise en œuvre de l'invention n'im- pacte donc pas la stabilité des routes installées dans le réseau. Une fois la délégation d'adresses IP acceptée par le deuxième dispositif, les adresses IP déléguées peuvent être utilisées sans délai par le premier dispositif pour traiter les paquets émis par ou à destination des équipements clients qui lui parviennent.
[0047] Dans un autre mode de réalisation, on peut envisager de modifier les tables de routage pour faire en sorte que les paquets de données associés à une adresse IP déléguée par un dit deuxième dispositif au premier dispositif soient directement acheminés vers le premier dispositif sans transiter par le deuxième dispositif. Dans cet autre mode de réalisation, les canaux de communication établis le cas échéant entre les premier et
deuxième(s) dispositifs ne sont utilisés que pour les besoins de contrôle (par exemple pour une demande de délégation d'adresses) ou pour l'acheminement de données pendant la durée nécessaire à la convergence du routage.
[0048] Dans un mode particulier de réalisation, les procédés de gestion et de collaboration sont mis en œuvre par un ordinateur.
[0049] L'invention vise également un programme d'ordinateur sur un support d'enregistrement, ce programme étant susceptible d'être mis en œuvre dans un ordinateur ou plus généralement dans un premier dispositif conforme à l'invention et comportant des instructions adaptées à la mise en œuvre d'un procédé de gestion tel que décrit ci-dessus.
[0050] L'invention vise également un programme d'ordinateur sur un support d'enregistrement, ce programme étant susceptible d'être mis en œuvre dans un ordinateur ou plus généralement dans un deuxième dispositif conforme à l'invention et comportant des instructions adaptées à la mise en œuvre d'un procédé de collaboration tel que décrit ci-dessus.
[0051] Chacun de ces programmes peut utiliser n'importe quel langage de programmation, et être sous la forme de code source, code objet, ou de code intermédiaire entre code source et code objet, tel que dans une forme partiellement compilée, ou dans n'importe quelle autre forme souhaitable.
[0052] L'invention vise aussi un support d’information ou un support d'enregistrement lisibles par un ordinateur, et comportant des instructions d'un programme d’ordinateur tel que mentionné ci-dessus.
[0053] Le support d’information ou d'enregistrement peut être n’importe quelle entité ou dispositif capable de stocker les programmes. Par exemple, le support peut comporter un moyen de stockage, tel qu’une ROM, par exemple un CD ROM ou une ROM de circuit microélectronique, ou encore un moyen d’enregistrement magnétique, par exemple un disque dur, ou une mémoire flash.
[0054] D’autre part, le support d’information ou d'enregistrement peut être un support transmissible tel qu’un signal électrique ou optique, qui peut être acheminé via un câble électrique ou optique, par lien radio, par lien optique sans fil ou par d’autres moyens.
[0055] Le programme selon l’invention peut être en particulier téléchargé sur un réseau de type Internet.
[0056] Alternativement, le support d’information ou d'enregistrement peut être un circuit intégré dans lequel un programme est incorporé, le circuit étant adapté pour exécuter ou pour être utilisé dans l’exécution des procédés de gestion et de collaboration selon l'invention.
[0057] Selon un autre aspect encore, l'invention vise également un système au moins un premier dispositif selon l'invention et au moins un deuxième dispositif selon l'invention, configuré pour traiter au moins une demande de délégation d'adresses IP reçue d'un dit premier dispositif.
[0058] Le système bénéficie des mêmes avantages cités précédemment que les premier et deuxième dispositifs.
[0059] On peut également envisager, dans d’autres modes de réalisation, que les procédés de gestion et de collaboration, les premier et deuxième dispositifs et le système selon l'invention présentent en combinaison tout ou partie des caractéristiques précitées.
Brève description des dessins
[0060] D'autres caractéristiques et avantages de la présente invention ressortiront de la description faite ci-dessous, en référence aux dessins annexés qui en illustrent un exemple de réalisation dépourvu de tout caractère limitatif. Sur les figures :
[Fig. 1] la figure 1, déjà décrite, représente des translations d'adresses effectuées par un équipement d'accès à un réseau embarquant une fonction NAT et un NAT opérateur (CGN) déployé dans le réseau ;
[Fig. 2] la figure 2 représente un système conforme à l'invention dans son environnement, dans un mode particulier de réalisation ;
[Fig. 3] la figure 3 représente un exemple d'architecture matérielle d'un ordinateur hébergeant un premier dispositif et/ou un deuxième dispositif du système de la figure 2 ; [Fig. 4] la figure 4 représente les modules fonctionnels d'un premier dispositif et d'un deuxième dispositif du système de la figure 2, conformes à l'invention, dans un mode particulier de réalisation ;
[Fig. 5] la figure 5 représente les principales étapes d'un procédé de gestion selon l'invention telles qu'elles sont mises en œuvre par un premier dispositif du système de la figure 2 ;
[Fig. 6] la figure 6 représente les principales étapes mises en œuvre par le premier dispositif de la figure 2, lorsqu'en réponse à un comportement suspect associé à une adresse IP qu'il gère, il exécute une action consistant à adresser une demande de délégation d'au moins une adresse IP à un deuxième dispositif du système de la figure 2 ; [Fig. 7] la figure 7 représente les principales étapes mises en œuvre par un deuxième dispositif du système de la figure 2, sollicité par le premier dispositif dudit système pour lui déléguer des adresses IP ;
[Fig. 8] la figure 8 représente, par un exemple illustratif, les traitements réalisés dans le contexte de l'invention par les premier et deuxième dispositif du système de la figure 2 sur des messages d'équipements clients servis par le premier dispositif ;
[Fig. 9] la figure 9 représente un exemple de système conforme à l'invention servant un équipement client de type CPE ;
[Fig. 10] la figure 10 illustre un réseau comprenant plusieurs niveaux de NAT opérateur, chaque niveau de NAT opérateur incluant un système conforme à l'invention.
Description de modes de réalisation de l'invention
[0061] La figure 2 représente, dans son environnement, un système 1 conforme à l'invention, dans un mode particulier de réalisation dans lequel il se trouve dans un réseau 2 de communications géré par un opérateur OP2. Aucune hypothèse n'est faite quant à la nature du réseau 2, qui peut être fixe ou mobile.
[0062] Le réseau 2 comprend une pluralité de NAT opérateur ou CGN (ou de façon équivalente, une pluralité d'instances de NAT opérateur ou de CGN), déployés sur des équipements distincts, et référencés CGN#1, CGN#2,..., CGN#M, où M désigne un nombre entier supérieur à 1. Chaque NAT opérateur CGN#n, n = l,...,M dispose d'au moins une adresse IP externe (par exemple publique) notée @IP-CGN#n qui lui a été allouée par l'opérateur OP2.
[0063] Dans le mode de réalisation décrit ici, on suppose que le réseau 2 est configuré pour utiliser le protocole IPv4 et que chaque NAT opérateur CGN#n, n=l,...,M est de type NAT44, tel que décrit dans le document RFC 3032 édité par l'IETF et intitulé « Traditional IP Network Address Translator (Traditional NAT) », janvier 2001. Chaque NAT opérateur CGN#n, n= l,...,M, est configuré avec un ensemble (ou pool) d'adresses IPv4 externes
(par exemple publiques) dédié et distinct, noté POOL#n, qu'il gère et peut utiliser pour traiter les paquets de données qu'il reçoit, ces paquets comprenant des données émises par ou destinées à des équipements clients du réseau 2.
[0064] Les adresses IPv4 d'un ensemble d'adresses POOL#n peuvent être contiguës (par exemple 1.2.3.0/24) ou non (par exemple 1.2.3.4/32 et 11.25.25.36/32). On suppose que des routes sont annoncées dans et en dehors du réseau 2 pour que le trafic destiné à une adresse IP d'un ensemble POOL#n soit reçu par le NAT opérateur CGN#n auquel est affecté cet ensemble d'adresses. Par souci de simplification, on fait l'hypothèse, dans le mode de réalisation décrit ici, que le réseau 2 implémente un seul niveau de NAT opérateur, c'est-à-dire que les paquets des équipements clients du réseau 2 ne sont traités, au sens de la translation d'adresses, que par un seul NAT opérateur parmi les NAT opérateur CG N# n, n= l,...,M.
[0065] Les adresses IPv4 de chaque ensemble POOL#n affecté à un NAT opérateur CGN#n peuvent être, dans le mode de réalisation décrit ici, partagées entre plusieurs équipements clients servis par le NAT opérateur CGN#n. Par « équipement client servi par un NAT opérateur » (ou de façon équivalente ici, « équipement client rattaché à ou géré par un NAT opérateur »), on entend que le NAT opérateur est en charge du traitement des paquets de données de cet équipement client (c'est-à-dire comportant des données émises ou destinées à cet équipement client), et notamment de la translation des adresses IP véhiculées dans ces paquets, c'est-à-dire la translation d'une adresse dite « interne » en une adresse dite « externe » (ou inversement selon le sens de communication considéré).
[0066] On note qu'un équipement client n'a pas nécessairement la connaissance du NAT opérateur désigné pour le servir. De même, le NAT opérateur CGN#n n'a pas nécessairement la connaissance explicite de l'équipement client auquel se rapporte un paquet qu'il doit traiter et qui est transporté en utilisant une adresse IP interne (l'information concernant l'équipement client peut toutefois être connue si un mécanisme tel que décrit par exemple dans le document RFC 7785, intitulé « Recommendations for Prefix Binding in the Context of Softwire Dual-Stack Lite », février 2016, est mis en œuvre par le NAT opérateur). Il exploite l'adresse IP « interne » utilisée pour transporter ce paquet jusqu'à lui pour la traduire en une adresse IP « externe » de l'ensemble POOL#n. Quel que soit le mode de fonctionnement du NAT opérateur CGN#n, il n'en demeure pas moins qu'il en résulte que le NAT opérateur CGN#n peut sélectionner, pour traiter les paquets de plusieurs équipements clients distincts, une même adresse IPv4 externe parmi les adresses IPv4 externes de l'ensemble POOL#n qu'il gère.
[0067] Dans la suite de la description, par souci de simplification, on omet parfois les notions « d'adresse interne/externe » pour qualifier les adresses IP considérées, sauf s'il y a lieu de distinguer ces adresses. En effet, ces notions sont relatives et définies par rapport au NAT opérateur considéré : au niveau d'un NAT opérateur donné, une adresse IP interne véhiculée par un paquet émis par un équipement client est translatée en une adresse IP externe (et vice versa, selon le sens de communication considéré). Toutefois, lorsque deux niveaux de NAT opérateur sont envisagés, un NAT opérateur du premier niveau procède à une translation d'une adresse interne telle qu'elle figure dans l'entête d'un paquet émis par un équipement client en une adresse externe, mais cette adresse externe est considérée comme une adresse interne du point de vue d'un NAT opérateur du deuxième niveau.
[0068] Aucune hypothèse n'est faite quant à la nature des équipements clients auxquels s'applique l'invention. Il peut s'agir de terminaux (par exemple des smartphones, des tablettes, des ordinateurs), d'équipements d'accès d'un réseau LAN (pour « Local Area Network » en anglais) au réseau 2 (par exemple des CPE auxquels sont connectés des terminaux), etc. A titre illustratif, dans le mode de réalisation illustré par la figure 2, les équipements clients servis par les NAT opérateur CGN#n, n = l,...,M sont des terminaux. [0069] Les critères de sélection et d'utilisation d'une adresse IP (alors dite « active ») d'un ensemble POOL#n sont spécifiques à chaque NAT opérateur ; chaque NAT opérateur décide localement (typiquement conformément à sa configuration) de la façon dont les adresses IP actives de l'ensemble qui lui a été affecté sont gérées. Par exemple, un NAT opérateur CGN#n, n = l,...,M, peut décider du nombre d'adresses IP à utiliser parmi celles de l'ensemble d'adresses POOL#n qu'il gère en fonction du ou des taux de partage avec le(s)quel(s) il a été le cas échéant configuré et du nombre d'équipements clients actifs (c'est-à-dire ayant une connexion active, représentée dans une base ou une table BIB maintenue par le NAT opérateur CGN#n, telle qu'évoquée précédemment) qu'il sert. Un même taux de partage (noté ici « l:x » pour indiquer qu'une même adresse IP peut être partagée entre x équipements clients, ou plus généralement qu'une même adresse IP externe peut être partagée entre x adresses IP internes compte tenu de la remarque précédente) peut être appliqué par le NAT opérateur CGN#n à chaque adresse IP (externe) destinée à être partagée. En variante, on peut envisager d'appliquer des taux de partage différents en fonction des adresses IP ou selon d'autres critères (par exemple des considérations géographiques). On peut également envisager de partager seulement certaines adresses IP, etc.
[0070] Les critères de rattachement d'un groupe d'équipements clients à un NAT opérateur CGN#n donné sont connus de l'homme du métier et ne sont pas détaillés ici ; ils relèvent du savoir-faire de l'exploitant des NAT opérateur CGN#n, n=l,...,M, à savoir ici de l'opérateur OP2 du réseau 2. Il en est de même pour ce qui concerne la manière dont les NAT opérateurs CGN#n, n=l,...,M, sont placés sur les chemins empruntés par les communications établies par les équipements clients qu'ils servent.
[0071] Les hypothèses évoquées précédemment ne sont pas limitatives en soi. L'invention peut également s'appliquer dans d'autres contextes, et notamment à des adresses IPv6, à d'autres types de NAT opérateur (par exemple NAT64, DS-Lite, NPTv6), les NAT opérateur du réseau 2 pouvant être tous d'un même type ou de types différents, colocalisés ou déployés sur des équipements matériels distincts, ou encore virtualisés et hébergés dans des infrastructures de type cloud. En outre, les NAT opérateur peuvent être déployés de façon distribuée dans le réseau 2 (avec des (instances de) NAT opérateur déployé(e)s au plus près des équipements clients) ou de façon centralisée. On peut également envisager plusieurs niveaux de NAT opérateur, c'est-à-dire qu'un paquet d'un équipement client du réseau 2 peut faire l'objet de translations d'adresses successives réalisées par des NAT opérateur déployés sur plusieurs niveaux au sein du réseau 2.
[0072] Par souci de simplification ici, on suppose que l'ensemble des NAT opérateur CGN#n, n= l,...,M déployés dans le réseau 2 appartiennent au système 1, et que chaque NAT opérateur CGN#n, n= l,...,M, embarque divers modules configurés pour mettre en œuvre, selon le contexte dans lequel se trouve le NAT opérateur CGN#n, un procédé de gestion ou un procédé de collaboration selon l'invention. Autrement dit, chaque NAT opérateur CGN#n, n= l,...,M embarque les modules fonctionnels d'un premier dispositif DI selon l'invention, susceptible de détecter un comportement suspect associé à une
adresse IP qu'il gère, et les modules fonctionnels d'un deuxième dispositif D2 selon l'invention, susceptible de collaborer avec un autre NAT opérateur du système 1 (sur la figure 2, par souci de simplification, les dispositifs DI et D2 n'ont été représentés que pour le NAT opérateur CGN#1) ; en fonction du contexte, le NAT opérateur CGN#n active les modules fonctionnels de l'un ou l'autre des dispositifs DI et D2 qu'il embarque. Dans le mode de réalisation décrit ici, un même NAT opérateur CGN#n du système 1 peut donc tantôt être un premier dispositif conforme à l'invention, tantôt un deuxième dispositif conforme à l'invention.
[0073] Bien entendu, cette hypothèse n'est pas limitative en soi et on peut envisager d'autres configurations pour le système 1. Par exemple, le système 1 peut n'intégrer qu'un sous- ensemble des NAT opérateur du réseau 2, et les NAT opérateur concernés peuvent embarquer uniquement les modules fonctionnels d'un premier dispositif DI selon l'invention ou uniquement les modules fonctionnels d'un deuxième dispositif D2 selon l'invention, étant entendu que parmi les NAT opérateur du système 1, se trouvent au moins un premier dispositif DI et au moins un deuxième dispositif D2 conformes à l'invention.
[0074] Par ailleurs, chaque NAT opérateur CGN#n, n=l,...,M, du système 1 dispose d'un canal de communication (par exemple ici un canal DOTS) établi avec au moins une fonction (ou un système) de détection d'attaques, connue en soi et non décrite en détail ici. Les NAT opérateur CGN#n, n= l,...,M du système 1 peuvent solliciter une ou plusieurs fonctions de détection d'attaques distinctes via les canaux DOTS ainsi établis. Dans l'exemple de la figure 2, on s'intéresse aux attaques de type DDoS, et la ou les fonctions de détection d'attaques avec lesquelles les NAT opérateur CGN#n, n= l,...,M, établissent des canaux DOTS sont des centres de mitigation DDoS ou DMS. Bien entendu, l'invention s'applique à d'autres types d'attaques informatiques et à d'autres fonctions/sys- tèmes de détection d'attaques (par exemple plus généralement à des centres AMS).
[0075] Chaque canal DOTS ainsi établi permet à chaque NAT opérateur CGN#n, n = l,...,M, de recevoir des centres DMS des informations concernant les attaques DDoS dont la source ou la destination est une adresse de l'ensemble POOL#n d'adresses IP qu'il gère. Plus particulièrement : pour recevoir via un tel canal DOTS des notifications d'un centre DMS concernant des attaques dont la cible est une adresse IP de l'ensemble POOL#n, le NAT opérateur CGN#n est configuré pour utiliser ici un mécanisme de souscription auprès du centre DMS tel que celui décrit dans le document RFC 9244 cité précédemment, notamment au point 8.1.1 ; pour recevoir via un tel canal DOTS des notifications d'un centre DMS concernant des attaques dont la source est une adresse IP de l'ensemble POOL#n, une nouvelle extension au mécanisme décrit dans le document RFC 9244 peut être spécifiée. La nouvelle extension proposée consiste à définir une nouvelle option « Uri-Query», appelée par exemple « source-address », permettant au NAT opérateur CGN#n d'indiquer dans une requête adressée au centre DMS, les adresses de l'ensemble POOL#n pour lesquelles il souhaite être notifié. La Table 1 illustre un exemple d'une telle requête incluant la nouvelle option « source-address » renseignée avec l'adresse IP « 1.2.3.4 ».
[0077] Les notifications envoyées par un centre DMS au NAT opérateur CGN#n peuvent être générées par le centre DMS suite à une détection locale ou suite à la réception par le centre DMS d'une notification en provenance d'autres entités (par exemple d'un autre centre DMS).
[0078] Dans le mode de réalisation décrit ici, un canal DOTS est également établi entre chaque NAT opérateur CGN#n, n=l,...,M du système 1 et un système de réputation REP_SYS. Ce canal DOTS est établi par exemple ici en utilisant une requête de configuration caractéristique du protocole RESTCONF. Cette requête comprend un filtre de souscription conditionnant les notifications envoyées par le système de réputation REP_SYS au NAT opérateur CGN#n. Le filtre de souscription désigne par exemple tout ou partie des adresses IP de l'ensemble POOL#n géré par le NAT opérateur CGN#n.
[0079] De façon connue, un tel système de réputation REP_SYS est adapté à évaluer un niveau de réputation d'une adresse IP, ce niveau de réputation reflétant le degré de confiance qu'on peut avoir en cette adresse IP. Il est établi en collectant des données spécifiques auprès de différentes entités (par exemple un routeur du réseau), comme par exemple le volume de trafic suspect associé à l'adresse IP, son appartenance éventuelle à une liste bloquée ou « block-list », son implication éventuelle dans des attaques informatiques, etc. Plus le niveau de réputation d'une adresse IP est élevé, plus son comportement est considéré comme sûr. A l'inverse, un niveau de réputation faible (typiquement inférieur à un certain seuil) traduit un risque élevé de comportement malveillant associé à l'utilisation de l'adresse IP (et donc du trafic émis avec une telle adresse comme adresse source). Le canal DOTS établi entre un NAT opérateur CGN#n et le système de réputation REP_SYS permet ainsi au NAT opérateur CGN#n d'obtenir les niveaux de réputation déterminés par le système de réputation REP_SYS pour les adresses IP de l'ensemble POOL#n que le NAT opérateur CGN#n gère.
[0080] Il convient de noter que les centres DMS et le système de réputation peuvent être exploités par une même entité administrative (par exemple par l'opérateur OP2 gérant les NAT opérateur CGN#n, n= l,...,M) ou par des entités administratives distinctes. En outre, aucune hypothèse n'est faite quant à la localisation de ces systèmes. Notamment, un même équipement matériel peut embarquer le système REP_SYS de réputation et un centre DMS.
[0081] Dans le mode de réalisation décrit ici, les NAT opérateur CGN#n, n=l,...,M sont hébergés par des équipements ayant l'architecture matérielle d'un ordinateur 3 telle que représentée sur la figure 3.
[0082] Chaque ordinateur 3 comprend un processeur PROC, une mémoire vive MEM, une mémoire morte ROM, une mémoire non volatile NVM, et des moyens COM de communications, permettant aux NAT opérateur CGN#n, n = l,...,M, de communiquer notamment avec d'autres entités du réseau 2 (et plus particulièrement de communiquer entre eux), avec les centres DMS et le système de réputation REP_SYS, ainsi qu'avec les équipements clients qu'ils servent. De tels moyens de communication sont connus en soi et ne sont pas décrits en détail ici.
[0083] La mémoire non volatile NVM de l'ordinateur 3 constitue un support d'enregistrement conforme à l'invention, lisible par le processeur PROC et sur lequel sont enregistrés ici des programmes d'ordinateur PROG1 et PROG2 conformes à l'invention.
[0084] Plus spécifiquement, le programme d'ordinateur PROG1 comporte des instructions définissant les principales étapes d'un procédé de gestion selon l'invention. Il définit des modules fonctionnels d'un premier dispositif DI selon l'invention, et incidemment, dans le mode de réalisation décrit ici, de chaque NAT opérateur CGN#n, n=l,...,M. Ces modules fonctionnels s'appuient ou commandent les éléments PROC, MEM, ROM, NVM, et COM de l'ordinateur 3 cités précédemment, et comprennent ici, pour chaque NAT opérateur CGN#n, comme illustré par la figure 4 : un module 4 de détection, configuré pour détecter un comportement suspect associé à une adresse IP active de l'ensemble POOL#n géré par le NAT opérateur CGN#n, sélectionnée par celui-ci pour traiter au moins un paquet d'un équipement client servi par le NAT opérateur CGN#n ; et un module 5 d'exécution, configuré pour exécuter au moins une action en réaction au comportement suspect détecté par le module 4 de détection. Plus particulièrement, dans le mode de réalisation décrit ici, le module EXEC d'exécution est configuré pour choisir la ou les actions à exécuter parmi un ensemble donné ACT d'actions, comprenant au moins les actions suivantes : o une action ACT1 consistant à retirer l'adresse IP associée à un comportement suspect de l'ensemble POOL#n d'adresses IP pouvant être sélectionnées par le NAT opérateur CGN#n pour traiter les paquets des équipements clients qu'il sert (ce retrait pouvant concerner seulement les connexions susceptibles d'être établies dans le futur par un équipement client, mais également les connexions en cours (autrement dit actives, telles que représentées dans la table BIB maintenue par CGN#n)) ; o une action ACT2 consistant à ajuster au moins un taux de partage d'au moins une adresse IP de l'ensemble POOL#n ; et o une action ACT3 consistant à demander une délégation d'adresses IP à au moins un autre NAT opérateur CGN#j du système 1, avec j*n. Par délégation, on entend ici que le NAT opérateur CGN#j accepte d'attribuer une ou plusieurs adresses IP de son ensemble POOL#j au NAT opérateur CGN#n pour que ce dernier puisse la ou les utiliser pour traiter des paquets d'équipements clients qui lui sont rattachés.
Le choix de l'action ou des actions exécutées par le module 5 d'exécution peut dépendre du contexte (par exemple de la nature du comportement malveillant détecté, du nombre de connexions actives traitées par le NAT opérateur CGN#n, du taux de partage effectif des adresses IP de l'ensemble POOL#n qu'il gère, de la gravité de l'attaque, etc.). Dans le mode de réalisation décrit ici, le module 5 est configuré pour choisir, en réponse à un comportement suspect associé à une adresse IP, au moins une action parmi l'action ACT2 d'ajustement d'au moins un taux de partage et l'action ACT3 de demande de délégation. Bien entendu, d'autres actions peuvent être sélectionnées par le module 5 en plus de l'une de ces deux actions, et d'autres actions peuvent être considérées dans l'ensemble ACT pris en compte par le module 5 d'exécution.
[0085] Le programme PROG1 définit également ici trois autres modules du NAT opérateur CGN#n en tant que premier dispositif DI conforme à l'invention, à savoir :
un module 6 de découverte, configuré pour découvrir les NAT opérateur du système 1 susceptibles de collaborer avec le NAT opérateur CGN#n et en particulier de lui déléguer des adresses IP ; un module 7 d'établissement, configuré pour établir des canaux de communication avec tout ou partie des NAT opérateur ainsi découverts ; et un module 8 de transmission/réception de transmission de données. Ce module 8 est notamment configuré pour transmettre et/ou recevoir des données via les canaux de communication établis par le module 7 d'établissement et pour transmettre et/ou recevoir des paquets de données des équipements clients servis par le NAT opérateur CGN#n.
[0086] Les modules 4 à 8 sont décrits plus en détail ultérieurement en référence aux étapes du procédé de gestion selon l'invention.
[0087] Le programme d'ordinateur PROG2 stocké dans la mémoire non volatile NVM de l'ordinateur 3 comporte des instructions définissant les principales étapes d'un procédé de collaboration selon l'invention. Il définit des modules fonctionnels d'un deuxième dispositif D2 conforme à l'invention, et incidemment, dans le mode de réalisation décrit ici, de chaque NAT opérateur CGN#n, n = l,...,M. Ces modules fonctionnels s'appuient ou commandent les éléments PROC, MEM, ROM, NVM, et COM de l'ordinateur 3 cités précédemment, et comprennent ici, pour chaque NAT opérateur CGN#n, comme illustré sur la figure 4 : un module 9 de réception, configuré pour recevoir en provenance d'un autre NAT opérateur CGN#k du système 1, avec k¥=n, une demande de délégation d'au moins une adresse IP de l'ensemble POOL#n d'adresses IP géré par le NAT opérateur CGN#n ; et un module 10 d'envoi, configuré pour envoyer au NAT opérateur CGN#k, une liste comprenant au moins une adresse IP de l'ensemble POOL#n que le NAT opérateur CGN#n accepte de lui déléguer.
[0088] Le programme PROG2 définit également ici un module 11 de transmission/réception de données.
[0089] Les modules 9 à 11 du NAT opérateur CGN#n sont décrits plus en détail ultérieurement en référence aux étapes du procédé de collaboration selon l'invention.
[0090] Il convient de noter qu'outre les modules 4 à 11 qui viennent d'être évoqués, chaque NAT opérateur CGN#n dispose également d'un module 12 de gestion de l'ensemble POOL#n d'adresses IP qui lui est affecté et d'un module 13 de translation d'adresses. Bien entendu, d'autres fonctions que la translation d'adresses peuvent être mises en œuvre par le NAT opérateur CGN#n (par exemple une fonction ALG, etc.), toutefois ces fonctions ne sont pas considérées ici par souci de simplification.
[0091] Le module 12 de gestion est notamment en charge de sélectionner une adresse IP dite externe parmi l'ensemble POOL#n (complété éventuellement par les adresses IP qui lui sont le cas échéant déléguées) pour traiter chaque paquet d'un équipement client qu'il reçoit portant une adresse IP dite interne, et de respecter le ou les taux de partage d'adresses IP avec le(s)quel(s) il a été configuré. L'adresse IP externe sélectionnée pour traiter un paquet d'un équipement client est mémorisée par le module 12 de gestion en association avec l'adresse IP interne, dans la table BIB maintenue par le NAT opérateur CGN#n, et stockée ici dans la mémoire non volatile NVM du NAT opérateur CGN#n. Comme mentionné précédemment, le module 12 de gestion peut associer une même adresse IP externe de l'ensemble POOL#n à plusieurs adresses IP internes distinctes,
conformément à un taux de partage avec lequel il a été configuré le cas échéant préalablement.
[0092] Le module 13 de translation d'adresses est configuré pour traiter les paquets d'équipements clients reçus par le NAT opérateur CGN#n, et translater le cas échéant les adresses IP de ces paquets conformément aux informations mémorisées dans la table BIB. La structure de la table BIB, son alimentation et sa maintenance, ainsi que le traitement des paquets des équipements clients servis par le NAT opérateur CGN#n conformément aux informations consignées dans la table BIB sont connus en soi et ne sont pas repris davantage ici.
[0093] Lorsqu'une même adresse IP externe est partagée entre plusieurs équipements clients, plusieurs entrées dans la table BIB associent cette adresse IP externe à plusieurs adresses IP internes distinctes. Afin de permettre au module 13 de translation d'associer la bonne adresse IP interne à un paquet de données qu'il reçoit, différentes techniques peuvent être envisagées de façon connue en soi. Par exemple, la différenciation peut se faire sur la base d'un état maintenu par le NAT opérateur CGN#n dans une table locale (un numéro de port associé à l'adresse IP interne dans la table BIB, un identifiant de l'équipement client, un protocole de transport, etc.), ou en mettant en œuvre un algorithme prévu à cet effet (par exemple pour un NAT opérateur de type NPTv6), etc.
[0094] Nous allons maintenant décrire, en référence à la figure 5, les principales étapes d'un procédé de gestion selon l'invention telles qu'elles sont mises en œuvre par chaque NAT opérateur CGN#n du système 1 lorsqu'il agit en tant que premier dispositif DI selon l'invention, c'est-à-dire lorsqu'il détecte un comportement malveillant associé à une adresse IP qu'il gère.
[0095] Dans le mode de réalisation décrit ici, chaque NAT opérateur CGN#n, n = l,...,M du système 1 procède préalablement à la découverte, via son module 6 de découverte, des autres NAT opérateur CGN#j, avec j=l,...,M et j*n, du système 1 (étape E10). A cet effet, le module 6 de découverte peut utiliser un protocole de routage dynamique tel que le protocole OSPF, ou dans le contexte d'un réseau 2 de type 5G, interroger la fonction NRF du réseau 2, etc.
[0096] Puis, chaque NAT opérateur CGN#n, n=l,..,M du système 1 établit, par l'intermédiaire de son module 7 d'établissement, un canal de communication avec chacun des NAT opérateur découverts lors de l'étape E10 de découverte (étape E20). Ces canaux de communication sont appelés dans la suite de la description canaux COGITARE (pour « Collaborative cGns for advanced Ip network repuTAtion safeguaRd/softEnings » en anglais). Ils peuvent être établis de sorte à être utilisés de façon unidirectionnelle (seul le NAT opérateur à l'origine de l'établissement du canal peut utiliser le canal pour envoyer une demande de délégation comme décrit ultérieurement) ou de façon bidirectionnelle (chaque NAT opérateur à un extrémité du canal peut envoyer une demande de délégation à l'autre NAT opérateur).
[0097] Dans le mode de réalisation décrit ici, ces canaux COGITARE sont chiffrés et reposent sur le protocole QUIC, décrit notamment dans le document RFC 9000 de l'IETF intitulé « QUIC: A UDP-Based Multiplexed and Secure Transport », mai 2021. En variante, les canaux COGITARE peuvent reposer sur un autre protocole que QUIC, par exemple sur le protocole IP-in-IP permettant d'encapsuler des paquets IP dans d'autres paquets IP moyennant l'établissement de tunnels (ou « tunneling » en anglais). Ces canaux peuvent ne pas être chiffrés, si les NAT opérateur sont considérés comme des entités de confiance, par exemple.
[0098] Pour mettre en œuvre l'invention dans le contexte du protocole QUIC, un nouveau paramètre de transport est défini, appelé par exemple « delegate_resources_enable ». Ce paramètre est valorisé ici à 1 par un NAT opérateur lorsque celui-ci est configuré pour mettre en œuvre un procédé de collaboration selon l'invention, c'est-à-dire qu'il est apte à déléguer des adresses IP du pool d'adresses qu'il gère à un autre NAT opérateur du système 1. On note que cette aptitude ne présume pas de la disponibilité effective d'adresses IP à déléguer au niveau du NAT opérateur en question, mais seulement de sa capacité, dans l'hypothèse où de telles adresses IP seraient disponibles dans le pool d'adresses qu'il gère, à déléguer de telles adresses IP, c'est-à-dire de sa capacité à mettre en œuvre le procédé de collaboration selon l'invention et à agir en tant que deuxième dispositif selon l'invention. Ainsi, on suppose ici que lorsqu'un NAT opérateur CGN#n initialise l'établissement d'un canal COGITARE avec un autre NAT opérateur CGN#j, j*n, il insère dans la trame QUIC qu'il envoie le paramètre « delegate_re- sources_enable » valorisé à 1. Il convient de noter que ce paramètre peut être utilisé de manière additionnelle par un NAT opérateur pour signaler à un autre NAT opérateur qu'en plus d'être configuré pour mettre en œuvre un procédé de collaboration selon l'invention, il est également configuré pour mettre en œuvre un procédé de gestion selon l'invention, c'est-à-dire qu'il peut être amené à solliciter l'autre NAT opérateur pour qu'il lui délègue des adresses IP. Cette information additionnelle peut être transmise à des fins informatives, et être exploitée par l'autre NAT opérateur pour effectuer un contrôle le cas échéant s'il reçoit une demande de délégation de ce NAT opérateur (par exemple pour déterminer si cette demande de délégation est cohérente avec ce que lui avait annoncé le NAT opérateur).
[0099] Si le NAT opérateur CGN#j avec lequel le NAT opérateur CGN#n tente d'établir un canal COGITARE n'est pas apte à collaborer avec un autre NAT opérateur du système 1 et à lui déléguer au moins une adresse IP, il répond par une trame QUIC dans laquelle le paramètre « delegate_resources_enable » est valorisé à 0, ou par une trame QUIC ne contenant pas ce paramètre. Le cas échéant, la procédure d'établissement d'un canal COGITARE est prématurément clôturée, et aucun canal COGITARE n'est établi.
[0100] A l'inverse, si le NAT opérateur CGN#j avec lequel le NAT opérateur CGN#n tente d'établir un canal COGITARE est apte à déléguer une ou plusieurs des adresses IP qu'il gère, il répond par une trame QUIC dans laquelle le paramètre « delegate_re- sources_enable » est valorisé à 1, et le canal COGITARE est établi selon les principes définis par le protocole QUIC.
[0101] Le NAT opérateur CGN#n mémorise ici dans une table CAPA stockée dans la mémoire non volatile NVM, pour chaque NAT opérateur CGN#j sollicité par le NAT opérateur CGN#n pour l'établissement d'un canal COGITARE, son aptitude ou non à déléguer des adresses IP. Ceci revient à mémoriser dans la table CAPA la valeur du paramètre « de- legate_resources_enable » retournée ou déduite de la trame QUIC envoyée par le NAT opérateur CGN#j en réponse à la demande d'établissement d'un canal COGITARE du NAT opérateur CGN#n. Le NAT opérateur CGN#n peut en outre mémoriser dans la table CAPA d'autres informations relatives à chaque NAT opérateur CGN#j sollicité, comme par exemple une ou plusieurs adresses IP permettant de le joindre.
[0102] Bien entendu, les valeurs 1 et 0 proposées pour valoriser le paramètre « delegate_re- sources_enable » ne sont données qu'à titre illustratif et ne sont pas limitatives en soi, d'autres valeurs pouvant être envisagées pour indiquer si un NAT opérateur est apte ou non à déléguer des adresses IP à un autre NAT opérateur. Par ailleurs, le paramètre
« delegate_ressources_enable », quelle que soit sa valeur, peut être échangé entre les NAT opérateur à tout moment (lors de la tentative d'établissement du canal COGITARE comme décrit précédemment, ou ultérieurement, une fois le canal établi).
[0103] Nous supposons maintenant que l'un des NAT opérateur du système 1, par exemple le NAT opérateur CGN#1 à titre illustratif, détecte par l'intermédiaire de son module 4 de détection un comportement suspect associé à une adresse IP de l'ensemble POOL#1 d'adresses IP qu'il gère (réponse oui à l'étape test E30). Par « comportement suspect », on entend ici que le comportement associé à l'adresse IP en question, notée dans la suite bad@IP, n'est pas normal et laisse présager que l'adresse IP est utilisée à des fins malveillantes (par exemple elle est associée à activité suspecte) ou ciblée par une attaque.
[0104] La détection d'un tel comportement suspect peut être réalisée par divers moyens.
[0105] Par exemple, le module 4 de détection du NAT opérateur CGN#1 peut recevoir une notification du système de réputation REP_SYS lui indiquant un niveau de réputation de l'adresse bad@IP inférieur à un seuil déterminé, avec lequel CGN#1 a été préalablement configuré et en deçà duquel le comportement associé à l'utilisation de l'adresse IP est considéré comme malveillant ou tout du moins suspect.
[0106] Selon un autre exemple, le module 4 de détection peut recevoir une notification d'une fonction de détection d'attaques d'un centre DMS (ou plus généralement d'un centre AMS) lui indiquant que l'adresse bad@IP appartient à une liste noire d'adresses IP considérées comme étant associées à des actions malveillantes ou que l'adresse bad@IP a été identifiée comme une cible ou utilisée comme l'origine d'une attaque.
[0107] Il convient de noter que dans les notifications du système REP_SYS ou du centre DMS peuvent viser un nom de domaine, auquel cas le module 4 de détection est configuré pour procéder à la résolution de ce nom de domaine en vue d'obtenir l'adresse bad@IP correspondante.
[0108] Selon un autre exemple encore, le module 4 de détection peut intégrer une fonction de détection d'attaques et déterminer lui-même localement que l'adresse bad@IP est associée à un comportement suspect.
[0109] Ces exemples ne sont donnés qu'à titre illustratif et ne sont pas limitatifs de l'invention. [0110] Suite à cette détection, CGN#1 vérifie ici que l'adresse bad@IP appartient bien à l'ensemble POOL#1 d'adresses IP qui lui a été affecté (ce qui est le cas ici) (étape E40). Le cas échéant, il active son module 5 d'exécution pour exécuter au moins une action en réponse à cette détection. On note que l'étape E40 de vérification est optionnelle (si elle n'est pas mise en œuvre, le module 5 d'exécution est activé sur détection par le module 4 du comportement suspect associé à l'adresse bad@IP).
[OUI] L'action ou les actions alors exécutées par le module 5 d'exécution peuvent être sélectionnées par celui-ci en fonction du contexte. Comme mentionné précédemment, dans le premier mode de réalisation décrit ici, le module 5 d'exécution choisit d'exécuter au moins une action parmi l'ensemble ACT d'actions comprenant : l'action ACT1 consistant à retirer l'adresse bad@IP des adresses IP de l'ensemble POOL#1 pouvant être sélectionnées par CGN#1 pour traiter les paquets des équipements clients qu'il sert (désignées plus simplement dans la suite par « adresses IP actives »). Il convient de noter que ce retrait peut concerner uniquement les connexions futures susceptibles d'être établies par des équipements clients (typiquement les paquets concernant d'autres équipements clients que ceux déjà servis par CGN#1 au moment du retrait), et/ou également les connexions actives (c'est-
à-dire en cours). Le choix de l'une ou l'autre des stratégies peut résulter d'une politique de l'opérateur OP2, différer en fonction du contexte (par exemple de la localisation de la source de l'attaque), etc. Par exemple, le maintien de l'adresse bad@IP pour traiter les paquets caractéristiques de connexions actives peut être justifié lorsque la source d'une attaque est interne au réseau 2, et/ou pour éviter de devoir migrer tous les équipements clients servis avec l'adresse bad@IP par CGN#1 ; l'action ACT2 consistant à ajuster au moins un taux de partage d'au moins une adresse IP de l'ensemble POOL#1 ; par exemple, au moins un taux de partage peut être augmenté si le NAT opérateur CGN#1 ne dispose plus d'adresses IP pour pouvoir servir les équipements clients qui lui sont rattachés (par exemple pour passer de 1: 10 à 1 :20 ou de 1:2 à 1:5). Cet ajustement dynamique d'au moins un taux de partage permet avantageusement de compenser le comportement malveillant associé à l'adresse bad@IP, et en particulier, son retrait le cas échéant des adresses IP actives si l'action AGIT est également exécutée. On note qu'un tel ajustement dynamique peut porter de façon globale sur les taux de partage de toutes les adresses IP du pool POOL#1 (à l'exception du taux de partage de l'adresse bad@IP, qui peut au contraire être réduit voire inutilisé en cas de retrait), ou être appliqué de façon différenciée à seulement une partie des adresses IP du pool POOL#1. En outre, un taux de partage peut être ajusté à plusieurs reprises si besoin (par exemple si plusieurs notifications signalant le comportement suspect de plusieurs adresses IP distinctes sont reçues par le module 4 de détection) ; et l'action ACT3 consistant en une demande de délégation d'adresses IP adressée à au moins un autre NAT opérateur CGN#j du système 1, avec j* l. L'action ACT3 peut notamment être sélectionnée par le module 5 d'exécution lorsque les taux de partage des adresses IP actives de l'ensemble POOL#1 (distinctes de l'adresse bad@IP associée à un comportement suspect) ont atteint une valeur maximale, définie par exemple par l'opérateur OP2, rendant alors impossible la sélection l'action ACT2. Ceci n'est toutefois qu'un exemple illustratif, et l'action ACT3 peut être sélectionnée par le module 5 d'exécution dans d'autres contextes.
[0112] Dans le mode de réalisation décrit ici, le module 5 d'exécution est configuré pour choisir, en réponse au comportement suspect de l'adresse bad@IP, au moins l'une des actions ACT2 ou ACT3, puis pour exécuter la ou les actions ainsi choisies (étape E50). Il peut par ailleurs, en complément de l'action ACT2 et/ou ACT3, exécuter également l'action AGIT. Bien entendu, l'invention ne se limite pas aux actions précitées et d'autres actions peuvent être envisagées et exécutées en variante par le NAT opérateur CGN#1 comme par exemple, mettre à jour un ensemble du système REP_SYS de réputation, marquer les paquets utilisant l'adresse bad@IP pour faciliter la reconnaissance et la classification du trafic de sorte que des puits de trafic puissent être mis en place dynamiquement dans le réseau 2, etc.
[0113] Par ailleurs, il convient de noter que la ou les actions sélectionnées par le module 5 d'exécution peuvent être exécutées par ce dernier durant une période de temps limitée. Par exemple, le module 5 d'exécution peut, conformément à l'action ACT1, retirer l'adresse bad@IP de la liste des adresses IP pouvant être sélectionnées pour traiter les messages des équipements clients qu'il sert pendant une durée donnée désignée ici par PAUSE_TIMER. Si à l'issue de la durée PAUSE_TIMER, le module 4 de détection ne détecte plus de comportement suspect associé à l'adresse bad@IP (par exemple, il ne
reçoit aucune nouvelle notification d'un système DMS ou d'un système REP_SYS portant sur cette adresse IP), dans ce cas il peut réactiver l'adresse bad@IP, autrement dit la réintégrer parmi les adresses IP de l'ensemble POOL#1 pouvant être sélectionnées pour traiter des messages parvenant à CGN#1.
[0114] Nous allons maintenant décrire plus en détail, en référence aux figures 6 et 7, le déroulement de l'étape E50 lorsque l'action ACT3 (demande de délégation d'adresses IP à un autre NAT opérateur) est sélectionnée par le module 5 d'exécution. La figure 6 illustre les étapes mises en œuvre par le NAT opérateur CGN#1 à l'origine de la demande de délégation, tandis que la figure 7 illustre les étapes mises en œuvre par un NAT opérateur du système 1 recevant et acceptant cette demande de délégation (c'est- à-dire agissant en tant que deuxième dispositif au sens de l'invention). Les étapes illustrées par la figure 7 correspondent à celles d'un procédé de collaboration selon l'invention. Il va de soi que bien qu'étant décrites sur la base d'un exemple illustratif, les étapes représentées dans les figures 5 à 7 s'appliquent à tous les NAT opérateur du système 1 en fonction du rôle joué par chacun d'entre eux (premier ou deuxième dispositif selon l'invention).
[0115] Dans le mode de réalisation envisagé ici, comme décrit précédemment, des canaux COGITARE ont été établis, préalablement lors de l'étape E20, par CGN#1 avec les NAT opérateurs du système 1 découverts lors de l'étape E10. Par ailleurs, lors de l'établissement de ces canaux COGITARE, CGN#1 a été informé par les NAT opérateur avec lesquels il a établi ces canaux, de leur aptitude ou non à déléguer des adresses IP à d'autres NAT opérateur du système 1. Cette information est stockée dans la table CAPA de CGN#1. Ainsi, suite à la sélection de l'action ACT3, le module 5 d'exécution de CGN#1 consulte la table CAPA et détermine à quel(s) NAT opérateur du système 1 il peut adresser sa demande de délégation d'adresses IP (il s'agit des NAT opérateur aptes à mettre en œuvre l'invention et donc susceptibles de déléguer des adresses IP, autrement dit dans l'exemple envisagé ici, ceux ayant indiqué un paramètre « delegate_re- sources_enable » valorisé à 1) (étape E50-1).
[0116] On note qu'en variante les étapes de découverte E10 et d'établissement E20 des canaux COGITARE peuvent être implémentées par le NAT opérateur CGN#1 après l'étape E30 de détection d'un comportement suspect associé à l'adresse bad@IP, par exemple après que le module 5 d'exécution a décidé d'exécuter l'action ACT3.
[0117] Le module 5 d'exécution de CGN#1 demande à au moins un des NAT opérateur identifiés lors de l'étape E50-1, de lui déléguer au moins une adresse IP parmi l'ensemble POOL d'adresses IP qu'il gère (étape E50-2). On note que le module 5 d'exécution peut adresser cette demande de délégation à tous les NAT opérateur identifiés lors de l'étape E50-1 ou seulement à une partie d'entre eux (il peut par exemple en choisir un aléatoirement, ou selon un critère déterminé, etc.). Par souci de simplification, on suppose ici que CGN#1 adresse sa demande de délégation à un unique NAT opérateur du système 1, à savoir au NAT opérateur CGN#2 (deuxième dispositif au sens de l'invention).
[0118] Dans le mode de réalisation envisagé ici de canaux COGITARE reposant sur le protocole QUIC, le module 5 d'exécution de CGN#1 demande une délégation d'adresses IP à CGN#2 en lui envoyant une trame QUIC, spécifiée pour les besoins de l'invention et appelée par exemple ici IP_RESOURCE_DELEGATE. Cette trame est envoyée par CGN#1 à CGN#2 via le canal COGITARE établi entre eux. Elle peut être vide (et donc ne contenir aucun paramètre), ou en variante contenir un ou plusieurs paramètres précisant la demande de CGN#1, comme par exemple un paramètre nommé ici « requested-size »
indiquant une préférence concernant la taille de l'espace des adresses IP à déléguer, ou de façon équivalente un paramètre nommé ici « requested-nb » indiquant un nombre d'adresses déléguées souhaitées, un paramètre nommé ici « requested-af » indiquant le type d'adresses IP déléguées souhaitées (par exemple valorisé à 0 pour des adresses IPv4 et à 1 pour des adresses IPv6, l'absence de ce paramètre pouvant être considérée comme équivalent à une valorisation du paramètre à 0, c'est-à-dire comme désignant des adresses IPv4), etc.
[0119] Ainsi, à titre illustratif, une trame IP_RESOURCE_DELEGATE comprenant un paramètre « requested -size » valorisé à 32 (bits) et ne contenant pas de paramètre « requested- af » indique une demande de délégation d'une unique adresse IPv4 (le paramètre « re- quested-size » combiné à l'absence de paramètre « requested-af » indique en effet un nombre d'adresses IP déléguées souhaitées). Bien entendu, d'autres paramètres peuvent être inclus dans la demande de délégation IP_RESOURCE_DELEGATE, tels que par exemple, une durée de délégation souhaitée, etc.
[0120] En référence à la figure 7, la trame IP_RESOURCE_DELEGATE est reçue par CGN#2, par son module 9 de réception, via le canal COGITARE établi avec CGN#1 (étape F10). [0121] Si CGN#2 accepte la demande de délégation de CGN#1 (réponse oui à l'étape test F20), il établit une liste « address-list » d'adresses IP comprenant au moins une adresse IP disponible, sélectionnée dans l'ensemble POOL#2 que CGN#2 gère et qu'il est prêt à déléguer à CGN#1 (étape F40). Il convient de noter que les adresses IP déléguées à CGN#1 sont destinées à être utilisées par celui-ci pour traiter des messages d'équipements clients qui lui sont rattachés ; elles ne doivent donc pas être utilisées pour traiter des messages échangés dans le cadre de connexions actives d'équipements clients servis par CGN#2, ni pour de futures connexions. En dehors de l'absence de trafic associé aux adresses IP de la liste « address-list », CGN#2 peut envisager d'autres critères pour sélectionner les adresses de l'ensemble POOL#2 qu'il accepte de déléguer à CGN#1 : il peut par exemple les sélectionner de façon aléatoire parmi les adresses non utilisées (c'est-à-dire qui ne sont pas actives) de l'ensemble POOL#2, ou sélectionner celles qui n'appartiennent pas à une « block-list », etc. CGN#2 peut en outre, pour établir la liste « address-list », tenir compte des préférences de CGN#1 indiquées le cas échéant dans sa demande de délégation (cf. paramètres « requested-size », « requested-nb », « re- quested-af », etc.). En variante, CGN#2 peut être configuré pour ignorer, lorsqu'il établit la liste « address-list », les préférences indiquées par CGN#1.
[0122] Dans le mode de réalisation décrit ici, comme détaillé davantage ultérieurement, après avoir délégué une adresse IP de l'ensemble POOL#2 à CGN#1, CGN#2 continue d'être impliqué dans la gestion du trafic destiné à ou émis en utilisant cette adresse IP. Plus particulièrement, il est configuré pour encapsuler, via son module 11 de transmission/ré- ception, dans le canal COGITARE établi avec CGN#1, tous les paquets qu'il reçoit à destination de cette adresse IP déléguée pour les transmettre à CGN#1, et à l'inverse, désencapsuler les paquets utilisant cette adresse IP déléguée qu'il reçoit via le canal COGITARE établi avec CGN#1 pour les transmettre à leurs destinataires respectifs. Lors de ces opérations, CGN#2 est configuré pour ne pas effectuer de translation de l'adresse IP déléguée (contrairement à ce qu'il fait avec les adresses IP de l'ensemble POOL#2 dont l'usage lui est réservé, c'est-à-dire qui ne sont déléguées à aucun autre NAT opérateur). Ce mode de réalisation permet avantageusement d'éviter une mise à jour des tables de routage dans le réseau 2, puisque CGN#2 continue de gérer le trafic associé aux adresses IP qu'il délègue à d'autres NAT opérateur du système 1.
[0123] Une fois la liste « address-list » établie, CGN#2 mémorise dans une table nommée ici DELEG stockée par exemple dans sa mémoire non volatile NVM, les adresses IP de la liste « address-list » déléguées à CGN#1 en association avec un identifiant de CGN#1, par exemple son adresse IP @IP-CGN#1.
[0124] CGN#2 envoie ensuite, par le biais de son module 10 d'envoi et via le canal COGITARE établi avec CGN#1, une réponse favorable à la demande de délégation de CGN#1 incluant la liste « address-list » ainsi établie (étape F50). Dans le mode de réalisation décrit ici d'un canal COGITARE reposant sur le protocole QUIC, la réponse de CGN#2 est une trame IP_RESOURCE_DELEGATE incluant la liste « address-list ». Cette réponse peut inclure par ailleurs d'autres informations, comme par exemple un paramètre nommé ici « validity » indiquant la durée pendant laquelle les adresses IP de la liste « address-list » est déléguée à CGN#1, un paramètre nommé ici « rate-limit » représentatif du volume maximum de trafic associé à l'usage d'une adresse IP déléguée de la liste « address-list » que CGN#2 peut gérer (compte tenu du fait qu'il reste impliqué dans la gestion de ce trafic comme indiqué précédemment), etc.
[0125] La réponse IP_RESOURCE_DELEGATE de CGN#2 est reçue par CGN#1, et transmise à son module 5 d'exécution (étape E50-3). Le module 5 d'exécution enregistre alors dans une table CGN_PEERS, stockée par exemple dans la mémoire non volatile NVM, la ou les offres de délégation reçues des NAT opérateur au(x)quel(s) il a envoyé une demande de délégation à l'étape E50-2, autrement dit, dans l'exemple illustratif envisagé ici de CGN#2 (étape E50-4). Plus particulièrement, dans le mode de réalisation décrit ici, le module 5 d'exécution de CGN#1 mémorise dans la table CGN_PEERS, pour chaque NAT opérateur lui ayant délégué des adresses IP (c'est-à-dire dans l'exemple envisagé, pour CGN#2) : un identifiant du NAT opérateur (c'est-à-dire dans l'exemple envisagé, un identifiant de CGN#2) ; la liste des adresses déléguées par le NAT opérateur (c'est-à-dire dans l'exemple envisagé, la liste « address-list ») ; la durée de validité de la délégation d'adresses par le NAT opérateur (c'est-à-dire dans l'exemple envisagé, la durée indiquée par CGN#2 dans le paramètre « validity ») ; et le volume maximum de trafic associé aux adresses déléguées par le NAT opérateur pouvant être géré par celui-ci (c'est-à-dire dans l'exemple envisagé, le volume indiqué par CGN#2 dans le paramètre « rate-limit »).
[0126] Par souci de simplification ici, on suppose une même valeur de durée de validité et de volume maximum pour l'ensemble des adresses IP de la liste « address-list ». Toutefois, cette hypothèse n'est pas limitative en soi et on peut envisager des valeurs qui diffèrent en fonction des adresses IP déléguées.
[0127] Dès lors, CGN#1 est en mesure d'utiliser les adresses IP déléguées répertoriées dans la table CGN_PEERS en plus des adresses IP de l'ensemble POOL#1 (sauf celles retirées le cas échéant lors de l'exécution de l'action ACT1) pour traiter les paquets des équipements clients qu'il reçoit (étape E50-5). Ainsi, grâce à l'invention, on étend de facto l'ensemble POOL#1 dont le CGN#1 bénéficie pour traiter les paquets qui lui parviennent.
[0128] Si les adresses IP déléguées à CGN#1 sont associées à une durée de validité limitée, alors CGN#1 est configuré localement pour utiliser ces adresses IP déléguées uniquement pendant une période de temps inférieure ou égale à cette durée de validité. Si
CGN#1 a besoin d'utiliser une adresse IP déléguée au-delà de la durée de validité spécifiée par CGN#2, alors CGN#1 peut être configuré pour demander à CGN#2 une extension de cette durée de validité ou pour demander à un autre NAT opérateur du système 1 la délégation d'autres adresses IP et restituer le cas échéant la ou les adresses IP déléguée dont la durée de validité a expiré à CGN#2. On note que CGN#1 peut restituer une adresse IP déléguée par CGN#2 avant l'expiration de sa durée de validité, par exemple en envoyant une trame QUIC à CGN#2 introduite pour les besoins de l'invention appelée par exemple RELEASE_RESOURCES et incluant l'adresse IP déléguée en question.
[0129] Si aucune durée de validité n'est spécifiée, l'utilisation par CGN#1 d'une adresse IP déléguée peut être limitée à une période de temps définie par défaut (par exemple 24 heures), ou tant que CGN# 1 a besoin de l'adresse IP déléguée en question (par exemple tant que le module 4 de détection associe un comportement malhonnête à l'adresse bad@IP), ou encore tant que CGN#1 n'est pas notifié de cesser cette utilisation (par exemple par CGN#2 ou par l'opérateur OP2 du réseau 2), etc.
[0130] Par ailleurs, comme mentionné précédemment, dans le mode de réalisation décrit ici, le trafic associé à une adresse IP déléguée à CGN#1 par CGN#2 continue de transiter par CGN#2 via le canal COGITARE établi entre les deux NAT opérateur. Il en résulte que CGN#1 est configuré pour envoyer à CGN#2, via son module 8 de transmission/récep- tion, tous les paquets qu'il traite et pour lesquels il a sélectionné une adresse IP déléguée par CGN#2.
[0131] En outre, si un volume maximum de trafic pouvant être géré par CGN#2 a été indiqué à CGN#1 (typiquement via le paramètre « rate-limit »), CGN#1 est configuré préférentiellement pour respecter ce volume maximum, par exemple il peut être configuré pour distribuer le trafic associé à des équipements clients distincts sur plusieurs canaux CO- GTTARE, et donc sélectionner pour ces équipements clients distincts des adresses IP déléguées par des NAT opérateur distincts du système 1. CGN#2 peut en outre être configuré pour écrêter le trafic associé aux adresses IP déléguées à CGN#1 au-delà du volume maximum indiqué, si ce volume maximum n'est pas respecté par CGN#1.
[0132] La figure 8 illustre par un exemple ce qui vient d'être décrit, et plus particulièrement comment CGN#1 et CGN#2 traitent les paquets associés à une adresse IP déléguée par CGN#2 à CGN#1. Par souci de simplification, seuls les NAT opérateur CGN#1 et CGN#2 du système 1 sont représentés par la figure 8.
[0133] On suppose avec cette figure qu'après exécution de l'action ACT3, CGN#1 reçoit un paquet Ml d'un équipement client 14 auquel sont alloués une adresse IPv4 interne notée @IP14 et un numéro de port P14, par exemple @IP14= 10.2.25.5 et P14= 12345. Le paquet Ml véhicule des données émises par l'équipement client 14 et destinées à une entité destinataire, par exemple ici un serveur 15 identifié par une adresse IPv4 destinataire notée @IP15 et un numéro de port destinataire noté P15 ; par exemple @IP15=1.2.3.4, P15=9856.
[0134] Le paquet Ml émis par l'équipement client 14 est reçu par CGN#1 ; il est donc reçu par CGN#1 et l'entête du paquet contient l'adresse IP source et le numéro de port internes @IP14 et P14.
[0135] Sur réception du paquet Ml, CGN#1 via son module 12 de gestion consulte la table BIB stockée dans sa mémoire non volatile NVM et détermine si une entrée correspondant au couple (@IP14,P14) existe déjà dans la table.
[0136] Si aucune entrée correspondante n'existe dans la table BIB, le module 12 de gestion
sélectionne une adresse IP externe et, dans l'exemple envisagé ici, un numéro de port externe, notés respectivement @IP14ext et P14ext, pour traiter le paquet Ml en provenance de l'équipement client 14 (on note toutefois que le numéro de port P14 n'est pas nécessairement modifié par le module 12 de gestion). L'adresse IP @IP14ext est sélectionnée ici parmi les adresses IP déléguées par CGN#2 répertoriées dans la table CGN_PEERS. Une nouvelle entrée est alors créée par le module 12 de gestion dans la table BIB associant le couple (@IP14, P14) au couple (@IP14ext, P14ext). Par souci de simplification ici, on suppose que l'adresse @IP14ext est associée dans la table BIB uniquement à l'adresse IP interne @IP14.
[0137] Si une entrée qui correspond à ce paquet existe dans la table BIB, le module 12 de gestion extrait l'adresse IP et le numéro de port externes (@IP14ext, P14ext) renseignés pour cette entrée dans la table BIB.
[0138] Dans la suite, on considère à titre illustratif @IP14ext=25.25.65.2 et P14ext=4859.
[0139] CGN#1 translate ensuite l'adresse IP @IP14 et le numéro de port P14 internes du paquet Ml en l'adresse IP @IP14ext et le numéro de port P14ext externes (c'est-à-dire qu'il remplace dans l'entête du paquet @IP14 et P14 par @IP14ext et P14ext respectivement), résultant en un paquet modifié Ml'. Il convient de noter que comme évoqué précédemment, d'autres modifications peuvent être apportées par CGN#1 au paquet Ml. Toutefois par souci de simplification ici, de telles modifications ne sont pas décrites davantage ici.
[0140] Puis, dans le mode de réalisation décrit ici, il encapsule le paquet Ml' dans un paquet QUIC M2 (aussi couramment désigné par trame QUIC M2) ayant pour adresse IP source, l'adresse IP @IP-CGN#1 externe de CGN#1, par exemple @IP-CGN#1 = 11.12.13.14. Le numéro de port utilisé, noté PI, peut être un numéro de port choisi aléatoirement lors de l'établissement du canal COGITARE avec CGN#2, comme décrit par exemple dans le document RFC 6056 intitulé « Recommendations for Transport-Protocol Port Randomization », janvier 2011. Il convient de noter que dans l'exemple envisagé ici d'un canal de communication QUIC établi entre CGN#1 et CGN#2, c'est l'identifiant CID de la connexion établie entre les deux NAT opérateur qui est utilisé par ces derniers, et le numéro de port utilisé importe peu.
[0141] Comme l'adresse IP externe @IP14ext sélectionnée par CGN#1 pour traiter le paquet Ml est une adresse IP déléguée par CGN#2, CGN#1 transmet par l'intermédiaire de son module 8 de transmission/réception la trame M2 à CGN#2 via le canal COGITARE établi entre les deux NAT opérateur, pour que les données véhiculées par le paquet Ml' (ou de façon équivalente par le paquet Ml) soient acheminées par CGN#2 vers leur destinataire, c'est-à-dire vers le serveur S. La trame M2 a donc dans son entête comme adresse IP destinataire, l'adresse IP externe @IP-CGN#2 du CGN#2.
[0142] Sur réception de la trame M2, CGN#2 vérifie, à l'aide de sa table DELEG, si l'adresse IP source (c'est-à-dire ici l'adresse @IP-CGN#1) correspond à une adresse IP de son ensemble POOL#2 déléguée à CGN#1, la trame M2 étant reçue via le canal COGITARE établi avec CGN#1.
[0143] Si ce n'est pas le cas (par exemple pas d'entrée dans la table DELEG correspondant à l'adresse IP source @IP-CGN#1 de la trame M2), CGN#2 supprime la trame M2.
[0144] Si c'est le cas, CGN#2 désencapsule le paquet Ml' de la trame M2 puis transmet le paquet Ml' vers son destinataire, c'est-à-dire vers le serveur S, sans effectuer de translation d'adresses sur le paquet Ml'. Le paquet Ml' transmis vers le serveur S a donc, dans son entête :
comme adresse IP et numéro de port sources : l'adresse IP externe @IP14ext=25.25.65.2 déléguée par CGN#2 à CGN#1 et le numéro de port externe P14ext=4859 ; et comme adresse IP et numéro de port destinataires : l'adresse IP @IP15=1.2.3.4 et le numéro de port @P15=9856.
[0145] On suppose maintenant que le serveur S répond à l'équipement client 14 en lui envoyant un paquet M3 contenant des données. Le paquet M3 est émis par le serveur S avec l'adresse IP source @IP15=1.2.3.4 et le numéro de port source @P15=9856. Les données sont destinées à l'équipement client 14 et donc à l'adresse IP externe @IP14ext=25.25.65.2 déléguée par CGN#2 à CGN#1 et au numéro de port externe P14ext=4859.
[0146] Le paquet M3 étant destiné à une adresse IP de l'ensemble POOL#2 géré par le CGN#2, il est, dans le mode de réalisation décrit ici, envoyé vers CGN#2.
[0147] Sur réception du paquet M3, CGN#2 vérifie si l'adresse IP destinataire du paquet M3 est une adresse IP de l'ensemble POOL#2 d'adresses IP qu'il gère et déléguée à un autre NAT opérateur du système 1. Il utilise à cet effet sa table DELEG.
[0148] S'il ne trouve aucune entrée correspondante pour @IP14ext dans la table DELEG, mais qu'il s'agit bien d'une adresse IP appartenant à l'ensemble POOL#2, CGN#2 traite le paquet M3 selon une procédure NAT44 conventionnelle, et translate l'adresse IP externe @IP14ext et le numéro de port externe P14ext en une adresse IP interne et un numéro de port interne si une entrée est active localement dans sa table BIB.
[0149] Si une entrée de la table DELEG est trouvée par CGN#2, alors il encapsule dans le mode de réalisation décrit ici le paquet M3 dans une trame QUIC M4 (paquet au sens de l'invention) sans modifier l'adresse IP destinataire (c'est-à-dire l'adresse @IP14ext) du paquet M3 encapsulé dans la trame M4, et donc incidemment sans modifier les données que le paquet M3 contient. Il transmet ensuite par l'intermédiaire de son module 11 de transmission/réception la trame M4 à CGN#1, via le canal COGITARE établi entre les deux NAT opérateur. La trame M4 contient le paquet M3 (en particulier les données émises par le serveur S et destinées à l'équipement client 14), et a dans son entête comme adresse IP source, l'adresse IP @IP-CGN#2 du CGN#2, et comme adresse IP destinataire, l'adresse IP @IP-CGN#1 du CGN#1. Par souci de simplification, on omet ici les numéros de port utilisés entre CGN#1 et CGN#2, pour les raisons évoquées précédemment.
[0150] Sur réception de la trame M4, CGN#1 vérifie que l'adresse IP source @IP-CGN#2 de la trame M4 correspond à une entrée de sa table CGN_PEERS. Si ce n'est pas le cas, la trame M4 est supprimée.
[0151] Si l'adresse IP source @IP-CGN#2 de la trame M4 correspond à une entrée de la table CGN_PEERS, CGN#1 extrait le paquet M3 de la trame M4. Puis il vérifie dans sa table BIB si une entrée correspondant à l'adresse IP destinataire du paquet M3 (c'est-à-dire ici à l'adresse IP externe @IP14ext) existe.
[0152] Si aucune entrée n'existe dans la table BIB pour cette adresse IP, CGN#1 supprime le paquet M3.
[0153] Si une entrée existe (c'est-à-dire que cette adresse IP a été précédemment sélectionnée par CGN#1 pour traiter les messages d'un équipement client ou qu'une entrée dans la table BIB a été explicitement créée en utilisant une interface dédiée), il remplace dans le paquet M3 l'adresse @IP14ext et le numéro de port P14ext destinataires par l'adresse IP et le numéro de port internes qui leur sont associés dans la table BIB, en l'occurrence
ici par l'adresse IP interne @IP14 et par le numéro de port interne P14 de l'équipement client 14.
[0154] Puis le paquet M3 ainsi modifié désigné dans la suite par M3' est transmis à l'équipement client 14 par CGN#1.
[0155] Il convient de noter que ce qui vient d'être décrit pour des canaux COGITARE reposant sur le protocole QUIC peut être appliqué à l'identique à des canaux COGITARE reposant sur un autre protocole, dès lors que l'encapsulation des paquets Ml' et M3 est réalisée dans des messages conformes à cet autre protocole. Par exemple pour le protocole IP- in-IP, il convient d'encapsuler les paquets Ml' et M3 dans des paquets IP au lieu de les encapsuler dans des trames QUIC.
[0156] Dans l'exemple de la figure 2, les équipements clients du réseau 2 sont des terminaux communiquant directement avec les NAT opérateur du système 1. Comme évoqué précédemment, on peut envisager d'appliquer l'invention à d'autres types d'équipements clients du réseau 2 et notamment à des équipements d'accès au réseau 2 tels que des CPE reliant par exemple des terminaux connectés à un réseau local (LAN) au réseau 2. Dans ce cas, l'invention est appliquée de façon identique à ce qui vient d'être décrit pour un équipement client de type terminal au niveau d'un CPE. Toutefois, comme évoqué précédemment, il existe une étape de translation d'adresses supplémentaire au niveau du CPE, connue en soi.
[0157] La figure 9 illustre cette étape supplémentaire. Plus précisément, l'équipement client 14 de la figure 9 est maintenant un CPE (au lieu d'un terminal tel qu'indiqué dans la figure 8), utilisé comme équipement d'accès au réseau 2 par un terminal 16 connecté à un LAN. L'invention est appliquée par les CGN#1 et CGN#2 de façon identique à ce qui a été décrit en référence à la figure 8 pour le terminal 14. Dans la figure 9, le paquet Ml résulte toutefois d'une modification par le CPE 14 d'un paquet Ml_0 émis par le terminal 16 contenant des données destinées au serveur S, ce paquet Ml_0 ayant pour adresse IP et numéro de port sources, une adresse IP et un numéro de port internes notées respectivement @IP16 et P16, alloués par le CPE 14 au terminal 16. La modification effectuée par le CPE 14 sur le paquet Ml_0, résultant en le paquet Ml, consiste à remplacer dans l'entête du paquet Ml_0 l'adresse IP @IP16 et le numéro de port P16 internes par l'adresse IP @IP14 et le numéro de port P14 alloués au CPE 14. La modification inverse est appliquée par le CPE 14 au paquet M3' résultant en un paquet M3" alors envoyé au terminal 16.
[0158] Tout ce qui vient d'être décrit en référence aux figures 2 à 9 pour les NAT opérateur CGN#1 et CGN#2 peut s'appliquer de façon similaire ou identique aux autres NAT opérateur du système 1. En outre, le NAT opérateur CGN#1 peut obtenir des adresses IP déléguées par plusieurs NAT opérateur du système 1. Ce qui vient d'être décrit pour CGN#2 s'applique alors de façon similaire ou identique aux différents NAT opérateur délégant des adresses IP à CGN#1.
[0159] Dans le mode de réalisation décrit en référence aux figures 2 à 9, le système 1 est configuré de sorte que lorsqu'un NAT opérateur CGN#j du système 1 délègue une ou plusieurs adresses IP à un NAT opérateur CGN#k, avec k*j, CGN#j continue de recevoir le trafic associé à ces adresses IP déléguées. En d'autres termes, les tables de routage maintenues par les routeurs du réseau 2 ne sont pas modifiées, ce qui permet à CGN#k d'utiliser sans délai les adresses IP qui lui ont été déléguées, et ce de façon transparente pour les équipements clients qu'il sert. Dans un autre mode de réalisation, on peut envisager que suite à la délégation d'adresses IP par CGN#j à CGN#k, les tables de
routage soient modifiées de sorte que le trafic associé à ces adresses IP déléguées (entrant et sortant) soit acheminé directement vers CGN#j (sans transiter par le canal COGITARE établi entre CGN#j et CGN#k), le temps de la délégation.
[0160] Dans le mode de réalisation décrit en référence aux figures 2 à 9, on a fait l'hypothèse qu'un unique niveau de NAT opérateur est déployé dans le réseau. L'invention s'applique toutefois également dans un contexte où plusieurs niveaux (ou étages) de NAT opérateur sont déployés dans le réseau 2 (induisant plusieurs translations d'adresses successives appliquées aux messages transitant par le réseau). Dans un tel contexte, la délégation d'adresses IP est réalisée conformément à l'invention, de façon identique à ce qui vient d'être décrit, entre NAT opérateur appartenant à un même niveau.
[0161] La figure 10 illustre un exemple de réseau 2' comprenant deux niveaux de NAT opérateurs LEV1 et LEV2, le niveau LEV1 comprenant I NAT opérateur CGN l#m, m = l,..,I, formant un système 1-1 conforme à l'invention et le niveau LEV2 comprenant J NAT opérateur CGN2#k, k= l,...,J, formant un système 1-2 conforme à l'invention, I et J désignant des entiers supérieurs à 1. Dans chaque niveau LEVi, i=l,2, chaque NAT opérateur du système 1-i comprend les modules fonctionnels 4 à 13 précédemment décrits et est susceptible d'agir, selon le contexte, comme un premier dispositif ou un deuxième dispositif selon l'invention. Les procédés de gestion et de collaboration selon l'invention qui viennent d'être décrits en référence aux NAT opérateurs CGN#n, n= l,...,M, des figures 2 à 9 s'appliquent donc de façon similaire ou identique au sein de chaque niveau LEVi et plus particulièrement de chaque système 1-i conforme à l'invention, i=l,2, entre les NAT opérateurs de ce système. Autrement dit, chaque NAT opérateur CGNi#p du système 1-i déployé au niveau LEVi est susceptible de demander une délégation d'adresses IP ou de déléguer une ou plusieurs adresses IP à un ou plusieurs NAT opérateur CGNi#t, avec t*p, appartenant au même système 1-i et donc au même niveau LEVi que lui. Des canaux COGITARE (représentés par des doubles flèches dans la figure 10) peuvent ainsi être établis entre NAT opérateur d'un même niveau.
[0162] La figure 10 illustre différentes situations expérimentées par les systèmes 1-1 et 1-2 dans le réseau 2'.
[0163] Plus précisément, la figure 10a illustre l'état du réseau 2' et des systèmes 1-1 et 1-2 dans un état normal (conditions nominales). Chaque NAT opérateur au sein d'un système 1-i, i= 1,2 gère un ensemble d'adresses IP distinctes et utilisent les adresses qu'il gère pour traiter les paquets des équipements clients qu'il sert (CPE ou terminaux dans l'exemple de la figure 10). Chaque paquet d'un équipement client (émis ou destiné à ce dernier) transite successivement dans le réseau 2' par deux NAT opérateur appartenant respectivement au niveau LEVI et au niveau LEV2. Chaque NAT opérateur sélectionne pour traiter ce paquet une adresse IP dans l'espace POOL d'adresses IP qui lui a été affecté. Ainsi à titre illustratif dans la figure 10a, un message associé à un terminal 17 transite par le NAT opérateur CGN1#1 dans le système 1-1 et par le NAT opérateur CGN2#2 dans le système 1-2.
[0164] La figure 10b illustre une situation dans laquelle le module 4 de détection d'un CGNl#m du système 1-1, par exemple CGN1#1, détecte un comportement malveillant associé à une adresse qu'il gère et envoie via son module 5 d'exécution, en réponse à ce comportement malveillant, une demande de délégation d'au moins une adresse IP à un autre NAT opérateur du système 1-1, par exemple à CGN1#2. Dans l'exemple de la figure 10b, suite à la délégation d'au moins une adresse IP par CGN1#2 à CGN1#1,
CGN1#1 sélectionne une des adresses IP déléguées par CGN1#2 pour traiter les paquets associés au terminal 17. Ces messages, lorsqu'ils contiennent des données émises par le terminal 17 et destinées à un serveur 18, transitent par CGN1#1 qui remplace leur adresse IP interne par une adresse IP déléguée par CGN1#2 (ou inversement), puis les envoie via le canal COGITARE à CGN1#2 pour qu'ils soient envoyés vers le serveur 18. Conformément aux règles de routage établies dans le réseau 2, les paquets sont transmis par CGN1#2 à un NAT opérateur du système 1-2 déployé au niveau LEV2 (CGN1#2 n'effectuant alors aucune translation d'adresses pour les paquets en question), par exemple à CGN2#2, en charge d'appliquer aux paquets reçus de CGN1#2 une nouvelle étape de translation d'adresses avant qu'ils ne soient acheminés jusqu'au serveur 18. Les paquets émis par le serveur 18 contenant des données destinées au terminal 17 suivent le chemin inverse : ils transitent par CGN2#2 qui effectue une translation d'adresses, puis sont envoyés par CGN2#2 à CGN1#2 qui les transmet à son tour, dans le canal COGITARE, à CGN1#1 sans effectuer de translation d'adresses. CGN1#1, après avoir remplacé l'adresse IP externe déléguée utilisée pour les paquets par une adresse IP interne allouée au terminal 17, envoie ces paquets au terminal 17.
[0165] La figure 10c illustre une situation dans laquelle, dans chaque système 1-i déployé à chaque niveau LEVi, un comportement malveillant associé à une adresse IP gérée par un NAT opérateur du système 1-i est détecté, déclenchant une demande de délégation d'adresses IP et une délégation d'adresses IP à chaque niveau. Dans l'exemple illustré par la figure 10c, un comportement malveillant associé à une adresse IP gérée par le NAT opérateur CGN1#I du système 1-1 et un comportement malveillant associé à une adresse IP gérée par le NAT opérateur CGN2#2 du système 1-2 sont détectés, résultant en une délégation d'adresses IP par CGN1#1 à CGN1#I et en une délégation d'adresses IP par CGN2#J à CGN2#2.
[0166] Bien entendu, l'invention ne se limite pas à deux niveaux de NAT opérateur déployés dans le réseau, un nombre plus important de niveaux de NAT peut être envisagé, l'invention s'appliquant de la même façon que ce qui a été décrit précédemment en référence aux figures 2 à 9 indépendamment à chaque niveau.
[0167] Enfin, l'invention a été décrite en référence à des NAT opérateur. Toutefois, l'invention peut s'appliquer à d'autres dispositifs gérant une pluralité d'adresses IP susceptibles d'être partagées entre plusieurs équipements clients, comme par exemple à des dispositifs mettant en œuvre une fonction proxy utilisant ses propres adresses IP pour relayer des messages reçus. De tels dispositifs sont par exemple décrits dans les sections 5, 6 et 7 du document RFC 7620 évoqué précédemment. L'invention s'applique aussi lorsque les adresses IP gérées par les premier et/ou deuxième dispositifs ne sont pas partagées entre plusieurs équipements clients.
Claims
[Revendication 1] Procédé de gestion, par un premier dispositif (CGN#1 ; CGN1#1 ; CGN1#I, CGN2#2) localisé dans un réseau (2,2'), d'un premier ensemble d'adresses IP, ledit procédé comprenant : une étape (E30) de détection d'un comportement suspect associé à une adresse IP (bad@IP) dudit premier ensemble sélectionnée par le premier dispositif pour traiter au moins un paquet de données d'un équipement client (14,17) servi par le premier dispositif ; une étape (E50) d'exécution, suite à ladite détection, d'au moins une action parmi : o un ajustement (ACT2) d'au moins un taux de partage d'au moins une adresse IP du premier ensemble appliqué par le premier dispositif ; o une demande (ACT3), adressée à au moins un deuxième dispositif (CGN#2 ; CGN1#2 ; CGN1#1, CGN2#J) gérant un deuxième ensemble d'adresses IP, de délégation d'au moins une adresse IP du deuxième ensemble au premier dispositif pour que le premier dispositif puisse sélectionner ladite au moins une adresse IP déléguée pour traiter au moins un paquet de données d'au moins un équipement client servi par le premier dispositif.
[Revendication 2] Procédé de gestion selon la revendication 1 dans lequel l'étape (E30) de détection comprend la réception d'une notification d'une fonction de détection d'attaques (DMS) ou d'un système (REP_SYS) de réputation d'adresses IP.
[Revendication 3] Procédé de gestion selon la revendication 1 ou 2 comprenant en outre une étape (E10) de découverte dudit au moins un deuxième dispositif.
[Revendication 4] Procédé de gestion selon l'une quelconque des revendications 1 à 3 comprenant en outre une étape (E20) d'établissement avec ledit au moins un deuxième dispositif d'au moins un canal de communication.
[Revendication 5] Procédé de gestion selon la revendication 4 dans lequel ledit au moins un canal de communication est un canal de communication chiffré reposant sur le protocole QUIC.
[Revendication 6] Procédé de gestion selon l'une des revendications 1 à 5 dans lequel ladite demande de délégation comprend un nombre et/ou un type d'adresses IP déléguées souhaités.
[Revendication 7] Procédé de gestion selon l'une des revendications 1 à 6 comprenant en outre une étape (E50-3) de réception, en réponse à une dite demande de délégation adressée par le premier dispositif à un dit deuxième dispositif, au moins un élément parmi : une liste comprenant au moins une adresse IP déléguée par ce deuxième dispositif au premier dispositif ; une durée pendant laquelle ladite liste est déléguée au premier dispositif ;
une information représentative d'un volume maximum de trafic associé à l'usage d'une adresse IP déléguée par ledit deuxième dispositif au premier dispositif pouvant être géré par le deuxième dispositif.
[Revendication 8] Procédé de gestion selon l'une quelconque des revendications 1 à 7 comprenant en outre : une étape de réception, depuis une adresse IP source interne (@IP14), d'un premier paquet de données (Ml) comprenant des données destinées à une entité destinataire (15) ; une étape de remplacement de ladite adresse IP source interne (@IP14) par une dite adresse IP déléguée (@IP14ext) par un dit deuxième dispositif (CGN#2) au premier dispositif (CGN#1) et sélectionnée par le premier dispositif pour traiter ledit premier paquet de données (Ml) ; et une étape de transmission desdites données (Ml') avec ladite adresse IP déléguée (@IP14ext) audit deuxième dispositif (CGN#2), via un canal de communication établi avec lui, pour que lesdites données soient acheminées vers l'entité destinataire (15).
[Revendication 9] Procédé de gestion selon l'une quelconque des revendications 1 à 8 comprenant en outre : une étape de réception, via un canal de communication établi avec un dit deuxième dispositif (CGN#2), d'un deuxième paquet de données (M3) émis par une entité émettrice (15) et comprenant des données destinées à une adresse IP (@IP14ext) du deuxième ensemble d'adresses IP géré par le deuxième dispositif (CGN#2) ; si ladite adresse IP (@IP14ext) est déléguée au premier dispositif (CGN#1) par le deuxième dispositif et sélectionnée par le premier dispositif pour traiter des paquets de données d'un équipement client (14) servi par le premier dispositif, une étape de transmission desdites données vers une adresse IP interne (@IP14) allouée audit équipement client.
[Revendication 10] Procédé de gestion selon l'une quelconque des revendications 1 à 9 comprenant une étape de sélection d'au moins deux adresses IP déléguées par desdits deuxièmes dispositifs distincts pour traiter des paquets de données d'au moins deux équipements clients distincts
[Revendication 11] Procédé de gestion selon la revendication 3 ou 4 dans lequel l'étape (E10) de découverte et/ou l'étape (E20) d'établissement dudit canal de communication est mise en œuvre avant l'étape (E30) de détection.
[Revendication 12] Procédé de collaboration avec un premier dispositif (CGN#1 ; CGN1#2 ; CGN1#I, CGN2#2) localisé dans un réseau (2) et gérant un premier ensemble d'adresses IP comprenant une adresse IP (bad@IP) associée à un comportement suspect, ledit procédé étant destiné à être mis en œuvre par un deuxième dispositif (CGN#2 ; CGN1#2 ; CGN1#1, CGN2#J) gérant un deuxième ensemble d'adresses IP et comprenant :
une étape (F10) de réception, en provenance du premier dispositif, d'une demande de délégation d'au moins une adresse IP du deuxième ensemble au premier dispositif pour que le premier dispositif puisse sélectionner ladite au moins une adresse IP déléguée pour traiter au moins un paquet de données d'au moins un équipement client servi par le premier dispositif ; et une étape (F50) d'envoi au premier dispositif d'une liste comprenant au moins une adresse IP du deuxième ensemble déléguée par ledit deuxième dispositif au premier dispositif.
[Revendication 13] Procédé de collaboration selon la revendication 12 comprenant en outre : une étape de réception, via un canal de communication établi avec le premier dispositif, d'un premier paquets de données (M2) comprenant des données destinées à une entité destinataire (15) et émis avec une adresse IP source (@IP14ext) appartenant au deuxième ensemble d'adresses IP géré par le deuxième dispositif (CGN#2) ; si ladite adresse IP source (@IP14ext) est une dite adresse IP déléguée par le deuxième dispositif au premier dispositif, une étape de transmission desdites données vers l'entité destinataire (15) sans modifier ladite adresse IP source (@IP14ext) desdites données.
[Revendication 14] Procédé de collaboration selon la revendication 12 ou 13 comprenant en outre : une étape de réception d'un deuxième paquet de données (M3) comprenant des données émises par une entité émettrice (15) et destinées à une adresse IP destinataire (@IP14ext) appartenant au deuxième ensemble d'adresses IP géré par le deuxième dispositif (CGN#2) ; si ladite adresse IP (@IP14ext) est une dite adresse IP déléguée par le deuxième dispositif au premier dispositif, une étape de transmission desdites données au premier dispositif via un canal de communication établi avec ledit premier dispositif sans modifier ladite adresse IP destinataire (@IP14ext) desdites données.
[Revendication 15] Programme d'ordinateur (PROG1, PROG2) comportant des instructions pour la mise en œuvre d'un procédé de gestion ou d'un procédé de collaboration selon l'une quelconque des revendications 1 à 14 lorsque ledit programme est exécuté par un ordinateur (3).
[Revendication 16] Dispositif, dit premier dispositif (CGN#1), localisé dans un réseau (2), ledit premier dispositif gérant un premier ensemble d'adresses IP et comprenant : un module (4) de détection, configuré pour détecter un comportement suspect associé à une adresse IP dudit premier ensemble sélectionnée par le premier dispositif pour traiter au moins un paquet de données d'un équipement client servi par le premier dispositif ; un module (5) d'exécution configuré pour exécuter, suite à ladite détection, au moins une action parmi :
o un ajustement d'au moins un taux de partage d'au moins une adresse IP du premier ensemble appliqué par le premier dispositif ; o une demande, adressée à au moins un deuxième dispositif gérant un deuxième ensemble d'adresses IP, de délégation d'au moins une adresse IP du deuxième ensemble au premier dispositif pour que le premier dispositif puisse sélectionner ladite au moins une adresse IP déléguée pour traiter au moins un paquet de données d'au moins un équipement client servi par le premier dispositif.
[Revendication 17] Dispositif, dit deuxième dispositif (CGN#2), localisé dans un réseau (2), ledit deuxième dispositif gérant un deuxième ensemble d'adresses IP et comprenant : un module (9) de réception, configuré pour recevoir, en provenance d'un premier dispositif gérant un premier ensemble d'adresses IP comprenant une adresse IP associée à un comportement suspect, une demande de délégation d'au moins une adresse IP du deuxième ensemble au premier dispositif pour que le premier dispositif puisse sélectionner ladite au moins une adresse IP déléguée pour traiter au moins un paquet de données d'au moins un équipement client servi par le premier dispositif ; et un module (10) d'envoi, configuré pour envoyer au premier dispositif, une liste comprenant au moins une adresse IP du deuxième ensemble déléguée par ledit deuxième dispositif au premier dispositif.
[Revendication 18] Système (1, 1-1, 1-2) comprenant : au moins un premier dispositif (CGN#1, CGN1#1, CGN1#I, CGN2#2) selon la revendication 16 ; et au moins un deuxième dispositif (CGN#2, CGN1#2, CGN1#1, CGN2#J) selon la revendication 17, configuré pour traiter au moins une demande de délégation d'adresses IP reçue d'un dit premier dispositif.
Applications Claiming Priority (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
FRFR2213026 | 2022-12-08 | ||
FR2213026A FR3143150A1 (fr) | 2022-12-08 | 2022-12-08 | Procédé de gestion d’un ensemble d’adresses IP, procédé de collaboration et dispositifs configurés pour mettre en œuvre ces procédés. |
Publications (1)
Publication Number | Publication Date |
---|---|
WO2024121281A1 true WO2024121281A1 (fr) | 2024-06-13 |
Family
ID=86007729
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
PCT/EP2023/084648 WO2024121281A1 (fr) | 2022-12-08 | 2023-12-07 | Procédé de gestion d'un ensemble d'adresses ip, procédé de collaboration et dispositifs configurés pour mettre en œuvre ces procédés |
Country Status (2)
Country | Link |
---|---|
FR (1) | FR3143150A1 (fr) |
WO (1) | WO2024121281A1 (fr) |
Citations (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
EP2608491A1 (fr) * | 2011-12-20 | 2013-06-26 | Huawei Technologies Co., Ltd. | Procédé, dispositif et système pour allouer une adresse IP publique |
US20210136030A1 (en) * | 2018-05-02 | 2021-05-06 | Orange | Method for Sending an Information Item and for Receiving an Information Item for the Reputation Management of an IP Resource |
-
2022
- 2022-12-08 FR FR2213026A patent/FR3143150A1/fr active Pending
-
2023
- 2023-12-07 WO PCT/EP2023/084648 patent/WO2024121281A1/fr unknown
Patent Citations (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
EP2608491A1 (fr) * | 2011-12-20 | 2013-06-26 | Huawei Technologies Co., Ltd. | Procédé, dispositif et système pour allouer une adresse IP publique |
US20210136030A1 (en) * | 2018-05-02 | 2021-05-06 | Orange | Method for Sending an Information Item and for Receiving an Information Item for the Reputation Management of an IP Resource |
Non-Patent Citations (7)
Title |
---|
"Distributed Denial-of-Service Open Threat Signaling (DOTS) Telemetry", RFC 9244, June 2022 (2022-06-01) |
"QUIC: A UDP-Based Multiplexed and Secure Transport", RFC 9000, May 2021 (2021-05-01) |
"Recommendations for Prefix Binding in the Context of Softwire Dual-Stack Lite", RFC 7785, February 2016 (2016-02-01) |
"Scénarios with Host Identification Complications", RFC 7620, August 2015 (2015-08-01) |
"Traditional IP Network Address Translator (Traditional NAT", RFC 3032, January 2001 (2001-01-01) |
ALRWAIS SUMAYAH ET AL: "Under the Shadow of Sunshine: Understanding and Detecting Bulletproof Hosting on Legitimate Service Provider Networks", 2017 IEEE SYMPOSIUM ON SECURITY AND PRIVACY (SP), IEEE, 22 May 2017 (2017-05-22), pages 805 - 823, XP033108112, DOI: 10.1109/SP.2017.32 * |
SHIRASAKI Y ET AL: "NAT444; draft-shirasaki-nat444-00.txt", NAT444; DRAFT-SHIRASAKI-NAT444-00.TXT, INTERNET ENGINEERING TASK FORCE, IETF; STANDARDWORKINGDRAFT, INTERNET SOCIETY (ISOC) 4, RUE DES FALAISES CH- 1205 GENEVA, SWITZERLAND, 19 October 2009 (2009-10-19), XP015064751 * |
Also Published As
Publication number | Publication date |
---|---|
FR3143150A1 (fr) | 2024-06-14 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
EP3476095B1 (fr) | Procédé de communication udp via des chemins multiples entre deux terminaux | |
EP2297927B1 (fr) | Procede de reception d'un paquet de donnees en provenance d'un domaine ipv4 dans un domaine ipv6, dispositif et equipement d'acces associes | |
EP3476096B1 (fr) | Procédé de communication udp via des chemins multiples entre deux terminaux | |
FR3067550A1 (fr) | Procede de communication quic via des chemins multiples | |
EP3284224B1 (fr) | Procédé d'émulation dune connexion à chemins multiples | |
EP3318023B1 (fr) | Procédé d'optimisation de la charge d'un concentrateur de connexions réseau | |
EP2294798B1 (fr) | Procede de routage d'un paquet de donnees dans un reseau et dispositif associe | |
EP3857848B1 (fr) | Procédé d'allocation d'un identifiant à un noeud client, procédé d'enregistrement d'un identifiant, dispositif, noeud client, serveur et programmes d'ordinateurs correspondants | |
EP3991391A1 (fr) | Procédé de gestion d'une communication entre terminaux dans un réseau de communication, et dispositifs pour la mise en oeuvre du procédé | |
EP3788762A1 (fr) | Procédé d'envoi d'une information et de réception d'une information pour la gestion de réputation d'une ressource ip | |
EP1142269B1 (fr) | Procede d'adressage et serveur de noms et d'adresses dans un reseau numerique | |
WO2024121281A1 (fr) | Procédé de gestion d'un ensemble d'adresses ip, procédé de collaboration et dispositifs configurés pour mettre en œuvre ces procédés | |
EP3949287B1 (fr) | Passerelle et procédé de différentiation de trafic émis par la passerelle, dispositif et procédé gestion du trafic | |
WO2010072953A1 (fr) | SYSTEME D'ACHEMINEMENT D'UN PAQUET DE DONNEES IPv4 | |
FR3103921A1 (fr) | Procédé de coordination de la mitigation d’une attaque informatique, dispositif et système associés. | |
EP1432213B1 (fr) | Plate-forme de médiation et réseau de transport de messages | |
WO2023242318A1 (fr) | Procédé de communication entre un premier équipement et un serveur distant, procédé de gestion des communications, premier équipement, serveur distant et programme d'ordinateur correspondants. | |
WO2024068722A1 (fr) | Procedes de resolution de nom, de communication, de traitement de messages et serveur, dispositif client et noeud relais correspondants | |
WO2023117802A1 (fr) | Procédés d'identification d'au moins un serveur de mitigation et de protection d'un domaine client contre une attaque informatique, dispositifs et signal correspondants | |
FR3044195A1 (fr) | Procede et dispositif de traitement d'une annonce non legitime d'un bloc d'adresses ip | |
WO2021191567A1 (fr) | Procédé de gestion de communications et dispositifs associés |