WO2022084624A1 - Procédé et dispositif de priorisation de flux de paquets - Google Patents

Procédé et dispositif de priorisation de flux de paquets Download PDF

Info

Publication number
WO2022084624A1
WO2022084624A1 PCT/FR2021/051828 FR2021051828W WO2022084624A1 WO 2022084624 A1 WO2022084624 A1 WO 2022084624A1 FR 2021051828 W FR2021051828 W FR 2021051828W WO 2022084624 A1 WO2022084624 A1 WO 2022084624A1
Authority
WO
WIPO (PCT)
Prior art keywords
node
packets
router
protection parameter
expected value
Prior art date
Application number
PCT/FR2021/051828
Other languages
English (en)
Inventor
Bruno Decraene
Isabelle ATHIAS
Original Assignee
Orange
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Orange filed Critical Orange
Priority to US18/249,844 priority Critical patent/US20230388270A1/en
Priority to EP21806788.2A priority patent/EP4232926A1/fr
Publication of WO2022084624A1 publication Critical patent/WO2022084624A1/fr

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/02—Network architectures or network communication protocols for network security for separating internal from external traffic, e.g. firewalls
    • H04L63/0227—Filtering policies
    • 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
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
    • G06F21/55—Detecting local intrusion or implementing counter-measures
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/02—Network architectures or network communication protocols for network security for separating internal from external traffic, e.g. firewalls
    • H04L63/029—Firewall traversal, e.g. tunnelling or, creating pinholes
    • 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/1408—Network architectures or network communication protocols for network security for detecting or protecting against malicious traffic by monitoring network traffic
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/12—Detection or prevention of fraud
    • 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
    • H04L63/1458—Denial of Service

Definitions

  • the invention lies in the field of telecommunications, and more particularly networks consisting of routers routing IP packets.
  • All users of the transport IP network can also send packets to customer sites.
  • a very large number of users can therefore send packets, potentially at high speed.
  • Any attacker on the Internet can thus send a large quantity of packets to a client site and thus saturate the client interface and/or or the client router, thus carrying out a denial of service (DOS) attack.
  • DOS denial of service
  • It can also use many different traffic sources all directed to a single destination - the client site receiving the IPsec packets - thus performing a Distributed Denial of Service (DDOS) attack.
  • DDOS Distributed Denial of Service
  • a known solution is to deploy protective equipment capable of analyzing all flows/packets towards the customer site, to try to distinguish legitimate traffic from DDOS traffic, and to prioritize legitimate traffic over DDOS traffic. This solution has several drawbacks.
  • One of the aims of the invention is to remedy these drawbacks of the state of the art.
  • the invention improves the situation with the aid of a method for protecting a stream of packets in a network composed of packet router nodes, and stream transmitter and receiver nodes, the receiver node being connected to a node router processing the routing of a packet to the receiving node based on an expected value a protection parameter included in at least one field of a stream packet, the method being implemented by a device associated with the receiver node and comprising:
  • the routers are managed by an operator who has no knowledge of the legitimacy of the flows passing through the routers, since these flows are established by third-party entities.
  • a third-party entity is, for example, a company managing sender and receiver nodes of packet streams between sites or machines of the company, these sender and receiver nodes being collectively called client nodes.
  • This company is a customer of the operator of the router nodes, and/or of a so-called OTT (Over The Top) supplier, i.e. a supplier using for commercial purposes the resources and capacities of these same routers which however remain managed by their operator.
  • OTT Over The Top
  • the streams conveyed are protected by the routers, whereas these streams are not necessarily managed (that is to say generated, transmitted or received) by the operator of the routers.
  • the message comprising the value of the protection parameter can be a message sent directly or indirectly, from a flow management device to a router node.
  • This flow management equipment is associated with the receiver node of a flow, i.e. it can be included in a client node, i.e. in the transmitter node or in the receiver node , or in another entity such as, for example, equipment for monitoring or controlling or configuring client nodes. It can be for example an SD-WAN network controller node.
  • the packet processing performed by the router depends on the protection parameter received in the message.
  • a packet received by the router presents the expected value of the parameter in a determined field associated with the flow, it is processed according to a policy determined in advance, that is to say for example that it is assigned a higher priority (QoS).
  • QoS higher priority
  • another aspect of the policy mentioned above may disadvantage the flow to which the packet belongs, for example by lowering its priority, or by filtering it.
  • the sending of the message comprising the expected value of the protection parameter is triggered by obtaining information indicative of congestion between the sender node and the receiver node .
  • the effect of an attack can be neutralized even after it has started.
  • one of the first effects of an attack is the increase in the volume of data destined for the receiving node. This increase can be detected at several levels, for example at the level of the sender node which no longer manages to communicate correctly with the receiver node, at the level of a router node on which an excessive volume of data arriving in transit to the node receiver, or at the receiving node itself which receives an excessive volume of data.
  • the congestion is not detected at the level of the device transmitting the message of the protection parameter, the information indicative of a congestion is transmitted to it.
  • the method according to the invention represents a solution in reaction to an attack. It is also understood that the value of the parameter can be changed as frequently as necessary, among other things if the attacker discovers the correct value of the protection parameter.
  • a new message is retransmitted with a new value of the protection parameter, after expiration of a defined period.
  • the method according to the invention represents a solution for preventing an attack.
  • the message comprises several expected values of the protection parameter, each value corresponding to a different period of use.
  • this can be done in a planned and synchronized way with the sender of the flow, by means of an automatic change of the value of the protection parameter after a period determined in advance, without it it is necessary to resend the message.
  • This is particularly advantageous if an attack in progress makes it impossible to send a new message.
  • the method according to the invention represents a solution both in reaction to and in prevention of an attack.
  • this can also be done in reaction to an attack, without the need to resend a new message, by means of a change in the value of the protection parameter which is for example triggered by obtaining information indicative of congestion between the sender node and the receiver node.
  • the router node must also send a message to inform the sender node of the flow from when the value of the protection parameter has changed.
  • the invention further improves the situation with the aid of a process for prioritizing a flow of packets in a network composed of packet router nodes, and flow transmitter and receiver nodes, the receiver node being connected to a router node processing the routing of a packet destined for the receiver node according to an expected value of a protection parameter included in at least one field of a packet of the stream, the method being implemented by the node router connected to the receiver node and comprising:
  • the flows specified or expected by the client nodes are also expected by the receiving node connected to the receiving node. If these flows arrive as far as this router node while being intended for the client receiver node, they are routed as far as the client receiver node by being prioritized, only if the packets of such flows have the expected value of the protection parameter.
  • This prioritization is advantageous in any situation of heavy traffic to the receiving node causing slowdowns at the level of the router nodes or the links between them, when all the flows, without necessarily being illegitimate, are not those expected by the receiving node.
  • This advantage is all the more interesting in the event of an attack by DOS or DDOS towards a client node.
  • the prioritization comprises placing the packets in a queue having access to one or more output interfaces of the router node, the access having priority over at least one other waiting line.
  • the method further comprises:
  • the method further comprises sending the message comprising the expected value of the protection parameter, to a neighboring router node of the router node connected to the receiver node.
  • stream prioritization is made possible at the level of a neighboring node of the router node connected to the client node, preferably upstream of the stream. This is advantageous in the case of a DDoS attack, where the attacking flows arrive at the last router node from several immediately neighboring router nodes. The load of prioritizing flows is thus better distributed in the network of routers.
  • the protection parameter is included in the destination IPv6 address of the packets of the stream.
  • the protection solution covers the most common and most important flows, as they typically go to several recipients.
  • certain existing parameters specific to these tunnels can advantageously be used as protection parameter according to the invention.
  • IP tunnel are L2TP, GRE, UDP, SRv6 (Segment Routing IPv6).
  • the at least one field comprising the protection parameter is one or more of the fields of a list comprising:
  • the received stream passing through the router node can be processed according to several protection parameters, which represents a combination that is more difficult for an attacker to discover, while providing more flexibility to the sender/receiver of the flows to adapt the solution to its use cases.
  • a context-specific parameter such as SPI, specific to IPsec
  • SPI Session Initiation Protocol
  • IPsec IP address
  • the attacker also needs to discover the context (such as the type of tunnel the stream is using).
  • the message comprising the expected value of the protection parameter is a message from one of the following protocols:
  • the method according to the invention fits into an existing network architecture by reusing a communication protocol already used by router nodes.
  • This device capable of implementing in all its embodiments the flow protection method which has just been described, is intended to be implemented in equipment of the sub-network composed of the transmitter and receiver nodes of the flow, also called client network. It can be part of the receiver node or the sender node, or be part of a customer network management device, separate from the flow sender or receiver nodes, for example an SD-WAN controller node if the customer network is SD type -WAN. In all cases, this device is associated with the receiving node, that is, it is part of the same administrative domain.
  • the invention also relates to a device for prioritizing a flow of packets in a network composed of packet router nodes, and flow transmitter and receiver nodes, the receiver node being connected to a router node processing the routing of a packet to the receiver node as a function of an expected value of a protection parameter included in at least one field of a packet of the flow, the device being implemented in the router node connected to the receiver node and comprising a receiver, a transmitter, a processor and a memory coupled to the processor with instructions intended to be executed by the processor for:
  • This device capable of implementing in all its embodiments the process for prioritizing flows which has just been described, is intended to be implemented in a node of the subnet composed of router nodes, also called operator network . More specifically, this device is part of the router node connected to the receiver node of the client network.
  • the invention also relates to a computer program comprising instructions which, when these instructions are executed by a processor, lead the latter to implement the steps of the protection method, which has just been described.
  • the invention also relates to a computer program comprising instructions which, when these instructions are executed by a processor, lead the latter to implement the steps of the prioritization method, which has just been described.
  • the invention also relates to an information medium readable by a protection device, and comprising instructions of a computer program as mentioned above.
  • the invention also relates to an information medium readable by a prioritization device, and comprising instructions of a computer program as mentioned above.
  • the programs mentioned above may 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 partially compiled form, or in n any other desirable shape.
  • a medium may include a storage means, such as a ROM, for example a CD ROM or a microelectronic circuit ROM, or even a magnetic recording means.
  • a storage means such as a ROM, for example a CD ROM or a microelectronic circuit ROM, or even a magnetic recording means.
  • an information medium can be an integrated circuit in which a program is incorporated, the circuit being adapted to execute or to be used in the execution of the methods in question.
  • Figure 1 schematically represents a network comprising router nodes and client nodes in accordance with the invention, in a particular embodiment,
  • FIG. 3 presents an example of the structure of a prioritization device, implemented on the network side of routers, according to aspects of the invention.
  • FIG. 1 schematically represents a network comprising router nodes and client nodes in accordance with the invention, in a particular embodiment.
  • the network N1 comprises a subnetwork N2 composed of router nodes R1 to R4 managed by a telecommunications operator, called operator network, and a subnetwork N3 composed of client nodes C1 to C3 managed by a third party entity independent of the operator , called customer network.
  • the operator network N2 is for example an IP/MPLS network, also called a transport network.
  • the N3 client network can be VPN, SD-WAN, etc.
  • a flow F1 is established between the client node C1 and the client node C3.
  • the client node C1 is connected to the router node R1
  • the client node C3 is connected to the router node R3
  • the flow F1 sent by the node C1 to the client node C3 takes a route B1 starting at the client node C1, passing through the router nodes R1, R2 and R3, and ending at client node C3.
  • the client node C3 can receive other flows from other sources, such as for example a flow F2 emitted by the source A1, borrowing or intended to borrow a route B2 having in common with the route B1 the router node R3 and the client node C3.
  • the source A1 can be any type of equipment capable of connecting to a router node of the operator network N2.
  • the source A1 is illustrated by a cloud appearing outside the networks N2 or N3, but it may or may not be part of the operator network N2, or may or may not be part of the customer network N3.
  • This problem is often referred to in the literature as a denial of service attack, or a DoS (Denial of Service) attack.
  • the source A1, illustrated in figure 1 as being single for simplicity, can also be multiple, which aggravates the problem. This is called a distributed DoS attack, or DDoS attack (Distributed DoS, in English).
  • the multiple flows emitted by the multiple source A1, in other words the DDoS attacker can take different routes but they all end up on the router node R3 which is the last router node before the attacked node which is the client node C3.
  • the flows arriving at the router node R3 and which are not legitimately expected by the client node C3 and risk harming it must be filtered, that is to say either blocked or reduced in their volume or in their speed, or lowered in terms of priority (QoS).
  • QoS priority
  • Lowering the priority of flows is particularly advantageous if it is important to allow certain legitimate but unpredictable flows coming from the Internet to pass, as long as an attack is not in progress.
  • the streams arriving at the router node R3, and which are legitimately expected by the client node C3, are prioritized relative to the other streams.
  • a flow must be able to provide the router node R3 with a particular parameter before being transmitted by the router node R3 to its destination which is the client node C3.
  • This protection parameter comparable to a signature, must be known in advance by the router node R3. It is communicated in a signal originating from a device of the client network N3 intended for an entity of the transport network N2.
  • several alternative methods allow the router node R3 to obtain the necessary information, including the protection parameter.
  • a flow signaling protocol such as BGP FlowSpec (RFC5575 and its revision draft-ietf-idr-rfc5575bis “Dissemination of Flow Specification Rules”) and its extensions;
  • a configuration protocol such as NETCONF (RFC 6241 “Network Configuration Protocol (NETCONF)”, RESTCONF (RFC 8040 “RESTCONF Protocol”, CLI (Command Line Interface) or SNMP;
  • NETCONF Network Configuration Protocol
  • RESTCONF RESTCONF Protocol
  • CLI Common Line Interface
  • SNMP SNMP
  • API Application Programming Interface
  • the signaling source can be:
  • a client flow communication controller for example an SD-WAN controller, in the N3 network.
  • the signaling can pass through a router controller of the operator network N2, in cases where, for example, the routers of the network N2 are not able to receive signaling messages directly from the network N3.
  • This controller then acts as an intermediate device which adapts the protocol or the format of the signaling message before retransmitting it to a router.
  • the client node C1 sends its stream with the protection parameter of its choice (or of the choice of the client node C3).
  • the router node R1 monitors the headers of new flows originating from the client node C1.
  • the router node R1 discovers the protection parameter and signals it to the router node R3, directly or indirectly via a router controller of the operator network N2.
  • the router node R3 after having received the protection parameter, the router node R3 communicates it to the router nodes which are immediately neighboring it, that is to say the router nodes R2 and R4. Indeed all the flows intended for the client node C3 necessarily pass through one of the router nodes immediately upstream of the router node R3.
  • the burden of processing according to the invention prioritization, or prioritization with filtering
  • the streams intended for the client node C3 is distributed over several router nodes rather than over a single one.
  • the communication of the protection parameter to an upstream router node can be triggered by a downstream router node when the volume of flows received by this router reaches a threshold endangering the downstream node or the link between the router node upstream and the downstream router node.
  • the router node R3 protects itself by delegating the processing load (prioritization, or prioritization with filtering) to the router node R4, which is useful because it is through this node that the stream F2 passes.
  • the router node R4 can also communicate the protection code to an upstream router node (not illustrated in FIG. 1), recursively. The threshold for triggering this communication may depend on the capacities of the router node R4 and be different from that of the router node R3.
  • the protection parameter is also inserted into one or more fields of the packets of the F1 before they are sent by the client node C1.
  • the protection parameter is inserted in a single field of a packet, but in a variant embodiment it may consist of several parts which are distributed in several fields of a packet.
  • the flow F1 is an IPsec tunnel and the protection parameter is distributed over several fields, of which the SPI field preferably forms part.
  • the other fields that can be used are: the Protocol field (or the Next Header field in the case of IPv6), the source IP address field, the destination IP address field, the source port field, the destination port field.
  • Some SRv6 fields Segment Routing IPv6, RFC 8754), such as for example Segment List, Segment List [n], Tag, HMAC TLV.
  • the SPI field cannot be used but the other fields which have just been mentioned can be used.
  • the Key field of GRE Generic Routing Encapsulation
  • Other fields specific to IPv6 packets can also be used, such as Routing Header, Destination option, or Authentication Header.
  • IPv4 For security and particularly in IPv4, it may be preferable to distribute the protection parameter over several fields including at least the Protocol field, because the other fields (IP addresses and ports) are more easily discoverable by an attacker.
  • the protection device 100 implements the method for protecting a stream of packets, of which various embodiments have just been described.
  • Such a device 100 can be implemented in a flow sender or receiver node, or in a client flow communication controller (for example an SD-WAN controller).
  • the device 100 comprises a receiver 101, a transmitter 102, a processing unit 130, equipped for example with a microprocessor pP, and controlled by a computer program 110, stored in a memory 120 and implementing the protection method according to the invention.
  • the code instructions of the computer program 110 are for example loaded into a RAM memory, before being executed by the processor of the processing unit 130.
  • Such a memory 120 such a processor of the processing unit 130, such a receiver 101 and such a transmitter 102 are capable of, and configured for:
  • the prioritization device 200 implements the process for filtering a stream of packets, of which different embodiments have just been described.
  • Such a device 200 can be implemented in a packet flow router node, for example the router node connected to a client node destination of the flows.
  • the device 200 comprises a receiver 201, a transmitter 202, a processing unit 230, equipped for example with a microprocessor pP, and controlled by a computer program 210, stored in a memory 220 and implementing the method for prioritizing a flow of packets according to the invention.
  • the code instructions of the computer program 210 are for example loaded into a RAM memory, before being executed by the processor of the processing unit 230.
  • Such a memory 220, such a processor of the processing unit 230, such a receiver 201 and such a transmitter 202 are capable of, and configured for:
  • FIGS. 2 and 3 can be hardware or software.
  • Figures 2 and 3 illustrate only one particular way, among several possible ones, of carrying out the algorithm detailed above, in relation to figure 1 . Indeed, the technique of the invention is carried out either on a reprogrammable calculation machine (a PC computer, a DSP processor or a microcontroller) executing a program comprising a sequence of instructions, or on a dedicated calculation machine (for example a set of logic gates like an FPGA or an ASIC, or any other hardware module).
  • a reprogrammable calculation machine a PC computer, a DSP processor or a microcontroller
  • a dedicated calculation machine for example a set of logic gates like an FPGA or an ASIC, or any other hardware module.
  • the corresponding program (that is to say the sequence of instructions) can be stored in a removable storage medium (such as for example a USB key , a floppy disk, a CD-ROM or a DVD-ROM) or not, this storage medium being partially or totally readable by a computer or a processor.
  • a removable storage medium such as for example a USB key , a floppy disk, a CD-ROM or a DVD-ROM

Landscapes

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

Abstract

L'invention concerne un procédé de priorisation d'un flux de paquets, le procédé étant mis en œuvre par le nœud routeur connecté au nœud récepteur et comprenant : • la réception d'un message comprenant la valeur attendue du paramètre de protection, en provenance d'un dispositif associé au nœud récepteur, • la priorisation des paquets comprenant la valeur attendue du paramètre de protection.

Description

DESCRIPTION
Procédé et dispositif de priorisation de flux de paquets
1. Domaine de l'invention
L’invention se situe dans le domaine des télécommunications, et plus particulièrement des réseaux constitués de routeurs acheminant des paquets IP.
2. Etat de la technique antérieure
Dans de nombreuses usages de type VPN (Virtual Private Network, ou réseau privé virtuel), et en particulier pour les offres de type SD-WAN (Software Defined Wide Area Network, ou réseau métropolitain défini par logiciel) qui gagnent en popularité de nos jours, des tunnels IPsec sont établis entre des sites du VPN d'un client, par exemple une entreprise établie sur plusieurs sites. Ces tunnels IPsec sont transportés par un réseau IP ou MPLS qui n’a pas connaissance de ces tunnels IPsec. Ce réseau "de transport" est typiquement l’Internet du fait de son ubiquité, haut débit et bas coût.
Tous les utilisateurs du réseau IP de transport peuvent également envoyer des paquets vers les sites clients. Dans le cas de l’Internet, un très grand nombre d’utilisateurs (de l'ordre du milliard) peuvent donc envoyer des paquets, potentiellement à haut débit. Un attaquant quelconque dans l’Internet peut ainsi envoyer une grande quantité de paquets sur un site client et ainsi saturer l’interface client et/ou ou le routeur client, réalisant ainsi une attaque par déni de service (DOS). Il peut également utiliser de nombreuses sources de trafic différentes toutes dirigées vers une même destination - le site client destinataire des paquets IPsec - réalisant ainsi une attaque par déni de service distribué (DDOS). De ce fait, le tunnel IPsec n’a plus de ressources et la quasi-totalité de son trafic est détruit en amont de sa destination, typiquement sur le dernier routeur du réseau de transport IP/MPLS.
Une solution connue est de déployer des équipements de protection capable d’analyser tous les flux/paquets en direction du site client, d’essayer de distinguer le trafic légitime du trafic de DDOS, et de prioriser le trafic légitime au dépends du trafic de DDOS. Cette solution présente plusieurs inconvénients.
Cette solution repose sur de la force brute d’analyse de tous les paquets de tous les flux. Elle est donc intrinsèquement coûteuse et ne passe pas à l’échelle de la réalité. De plus, le travail nécessaire à l’analyse et la protection est beaucoup plus compliqué que le travail d’envoyer des paquets d’attaques. De ce fait, le défenseur est intrinsèquement dans une position d'infériorité par rapport à l’attaquant.
Cette solution ne peut garantir qu’elle peut/pourra distinguer les paquets ou les flux légitimes par rapport aux paquets ou flux d’attaques. Elle se base sur des heuristiques suite aux attaques précédentes ou sur le fait que l’attaquant a des chances d’envoyer des paquets/flux relativement semblables afin de se simplifier la vie, d’optimiser le travail des équipements attaquant et/ou utilise des équipements qu’il ne contrôle pas entièrement (attaques par réflexion). Mais un attaquant suffisamment motivé avec suffisamment de ressources (payées ou volées) a toutes les chances d’échapper à la détection.
Enfin, cette solution doit être dimensionnée pour la plus grosse attaque possible, même si celle-ci n’est subie qu’une seule fois par an. Ce coût maximum est difficile à amortir sur l’ensemble des attaques plus petites. Mais si l’opérateur ne fait pas cet investissement, d’une part le client ne peut plus avoir confiance dans l’offre et d’autre part l’attaquant connait le point faible.
Un des buts de l'invention est de remédier à ces inconvénients de l'état de la technique.
3. Exposé de l'invention
L'invention vient améliorer la situation à l'aide d'un procédé de protection d’un flux de paquets dans un réseau composé de nœuds routeurs de paquets, et de nœuds émetteur et récepteur du flux, le nœud récepteur étant connecté à un nœud routeur traitant le routage d'un paquet à destination du nœud récepteur en fonction d'une valeur attendue d'un paramètre de protection compris dans au moins un champ d'un paquet du flux, le procédé étant mis en œuvre par un dispositif associé au nœud récepteur et comprenant :
• l'émission d'un message comprenant la valeur attendue du paramètre de protection, à destination du nœud routeur connecté au nœud récepteur.
Dans un réseau classique, les routeurs sont gérés par un opérateur qui n'a pas la connaissance de la légitimité des flux traversant les routeurs, car ces flux sont établis par des entités tierces. Une entité tierce est par exemple une entreprise gérant des nœuds émetteurs et récepteurs de flux de paquets entre des sites ou des machines de l'entreprise, ces nœuds émetteurs et récepteurs étant collectivement appelés nœuds clients. Cette entreprise est cliente de l'opérateur des nœuds routeurs, et/ou d'un fournisseur dit OTT (Over The Top), c'est à dire un fournisseur utilisant à des fins commerciales les ressources et les capacités de ces mêmes routeurs qui toutefois restent gérés par leur opérateur.
Grâce à l'invention, les flux véhiculés sont protégés par les routeurs, alors que ces flux ne sont pas nécessairement gérés (c’est-à-dire générés, émis ou reçus) par l'opérateur des routeurs. Le message comprenant la valeur du paramètre de protection peut être un message envoyé directement ou indirectement, depuis un équipement de gestion de flux vers un nœud routeur. Cet équipement de gestion de flux est associé au nœud récepteur d'un flux, c’est-à-dire qu'il peut être compris dans un nœud client, c’est-à-dire dans le nœud émetteur ou dans le nœud récepteur, ou dans une autre entité comme par exemple un équipement de supervision ou de contrôle ou de configuration des nœuds clients. Ce peut être par exemple un nœud contrôleur de réseau SD-WAN. Le traitement des paquets effectué par le routeur est fonction du paramètre de protection reçu dans le message. Par exemple, si un paquet reçu par le routeur présente la valeur attendue du paramètre dans un champ déterminé et associé au flux, il est traité selon une politique déterminée à l'avance, c’est-à-dire par exemple qu'il est affecté d’une priorité (QoS) plus forte. Cela n'exclut pas que si au contraire le paquet ne présente pas la valeur attendue du paramètre de protection, un autre aspect de la politique mentionnée plus haut puisse défavoriser le flux auquel appartient le paquet, par exemple en en abaissant la priorité, ou en le filtrant.
Selon un aspect du procédé de protection d’un flux de paquets, l'émission du message comprenant la valeur attendue du paramètre de protection est déclenchée par l'obtention d'une information indicative d'une congestion entre le nœud émetteur et le nœud récepteur.
Grâce à cet aspect, l'effet d'une attaque peut être neutralisé même après qu'elle ait commencé. En effet, un des premiers effets d'une attaque est l'augmentation du volume des données à destination du nœud récepteur. Cette augmentation peut être détectée à plusieurs niveaux, par exemple au niveau du nœud émetteur qui n'arrive plus à communiquer correctement avec le nœud récepteur, au niveau d'un nœud routeur sur lequel arrive en transit un volume excessif de données à destination du nœud récepteur, ou au niveau du nœud récepteur lui-même qui reçoit un volume excessif de données. Si la congestion n'est pas détectée au niveau du dispositif émettant le message du paramètre de protection, l'information indicative d'une congestion lui est transmise. Dans ce mode, le procédé selon l'invention représente une solution en réaction à une attaque. On comprend également que la valeur du paramètre peut être changée aussi fréquemment que nécessaire, entre autre si l'attaquant découvre la bonne valeur du paramètre de protection.
Selon un aspect du procédé de protection d’un flux de paquets, un nouveau message est réémis avec une nouvelle valeur du paramètre de protection, après expiration d'une période définie.
Grâce à cet aspect, même si un attaquant découvre la valeur courante du paramètre de protection, elle aura changé même en cas d'attaque au niveau du nœud récepteur, à la condition que cette attaque n'empêche pas la réémission du message. Dans ce mode, le procédé selon l'invention représente une solution en prévention d'une attaque.
Selon un aspect du procédé de protection d’un flux de paquets, le message comprend plusieurs valeurs attendues du paramètre de protection, chaque valeur correspondant à une période différente d'utilisation.
Grâce à cet aspect, même si un attaquant découvre la valeur courante du paramètre de protection, elle est remplacée par une autre valeur fournie à l’avance.
Dans un mode, cela peut être fait de façon planifiée et synchronisée avec l’émetteur du flux, au moyen d’un changement automatique de la valeur du paramètre de protection au bout d'une période déterminée à l'avance, sans qu'il soit nécessaire de réémettre le message. Ceci est particulièrement avantageux si une attaque en cours rend impossible l'émission d’un nouveau message. Dans ce mode, le procédé selon l'invention représente une solution à la fois en réaction à, et en prévention d'une attaque.
Dans un autre mode, cela peut aussi être fait en réaction à une attaque, sans qu'il soit nécessaire de réémettre un nouveau message, au moyen d’un changement de la valeur du paramètre de protection qui est par exemple déclenché par l'obtention d'une information indicative d'une congestion entre le nœud émetteur et le nœud récepteur. Dans ce mode le nœud routeur doit également émettre un message pour informer le nœud émetteur du flux à partir de quel moment la valeur du paramètre de protection a changé.
L'invention vient de plus améliorer la situation à l'aide d'un procédé de priorisation d’un flux de paquets dans un réseau composé de nœuds routeurs de paquets, et de nœuds émetteur et récepteur du flux, le nœud récepteur étant connecté à un nœud routeur traitant le routage d'un paquet à destination du nœud récepteur en fonction d'une valeur attendue d'un paramètre de protection compris dans au moins un champ d'un paquet du flux, le procédé étant mis en œuvre par le nœud routeur connecté au nœud récepteur et comprenant :
• la réception d'un message comprenant la valeur attendue du paramètre de protection, en provenance d'un dispositif associé au nœud récepteur,
• la priorisation des paquets comprenant la valeur attendue du paramètre de protection.
On comprend que grâce à ce procédé les flux spécifiés ou attendus par les nœuds clients sont aussi attendus par le nœud récepteur connecté au nœud récepteur. Si ces flux arrivent jusqu'à ce nœud routeur tout en étant destinés au nœud récepteur client, ils sont routés jusqu'au nœud récepteur client en étant priorisés, uniquement si les paquets de tels flux présentent la valeur attendue du paramètre de protection.
Cette priorisation est avantageuse dans toute situation de fort trafic à destination du nœud récepteur engendrant des ralentissements au niveau des nœuds routeurs ou des liens entre eux, lorsque tous les flux, sans être forcément illégitimes, ne sont pas ceux attendus par le nœud récepteur. Cet avantage est d'autant plus intéressant en cas d'attaque par DOS ou DDOS vers un nœud client.
Le dispositif à l'initiative du message comprenant la valeur du paramètre de protection fait partie du même domaine administratif que le nœud récepteur client, ce domaine étant par exemple celui du réseau client. Le nœud routeur effectuant le filtrage, connecté au nœud récepteur, peut recevoir ce message directement du réseau client. Dans un autre mode de réalisation, il peut aussi le recevoir indirectement, si par exemple un équipement intermédiaire doit en modifier le format et/ou s'il n'est pas possible pour le nœud routeur de recevoir une signalisation directement du réseau client. Cet équipement intermédiaire peut être un contrôleur de flux faisant partie du réseau opérateur comprenant les nœuds routeurs, et ne comprenant pas les nœuds émetteur et récepteur, auquel le dispositif associé au nœud récepteur peut envoyer des signalisations.
Selon un aspect du procédé de priorisation d’un flux de paquets, la priorisation comprend la mise des paquets dans une file d'attente ayant accès à une ou plusieurs interfaces de sortie du nœud routeur, l'accès étant prioritaire sur au moins une autre file d'attente.
Grâce à cet aspect, le nœud routeur place un paquet marqué dans une file d’attente (queue) différente qui sera servie (utilisée) en priorité lors de l’émission des paquets sur le lien en sortie du nœud routeur. Cela peut être en priorité stricte, c’est-à-dire tant que cette queue a des paquets à envoyer, c’est la seule qui a accès à l’interface de sortie. En priorité moins stricte, la file d’attente prioritaire peut avoir des caractéristiques différentes des autres, par exemple une capacité plus grande (buffer plus grand), une politique d'élimination des paquets en débordement moins agressive ou rapide en cas de congestion, etc.
Selon un aspect du procédé de priorisation d’un flux de paquets, le procédé comprend en outre :
• le filtrage des paquets ne comprenant pas la valeur attendue du paramètre de protection.
Grâce à cet aspect, non seulement les flux spécifiés ou attendus par les nœuds clients sont routés en étant priorisés jusqu'à un nœud client par un nœud routeur, mais les autres flux sont modifiés défavorablement (la modification pouvant aller jusqu'à la destruction de tous les paquets du flux). Cette modification défavorable d'un flux est désignée par le terme de "filtrage" dans la suite. Même si les paquets reçus par le nœud routeur indiquent l'adresse de destination du nœud client, ils ne sont donc pas routés vers lui normalement ou selon le traitement par défaut si ces paquets ne présentent pas aussi la valeur attendue du paramètre de protection, dans le ou les champs attendus. Ainsi, une attaque par DOS ou DDOS vers le nœud client devient impossible.
Selon un aspect du procédé de priorisation d’un flux de paquets, le filtrage comprend un blocage des paquets, ou une destruction des paquets, ou un abaissement de la priorité des paquets.
Grâce à cet aspect, selon une politique appliquée par l'opérateur et décidée en concertation ou non avec le client, lorsqu'un paquet ne présente pas la bonne valeur du paramètre de protection, soit la priorité du paquet est abaissée, ce qui ralentit l'arrivée des paquets du flux sur le nœud client récepteur en lui permettant de continuer à recevoir d'autres flux, soit tous les paquets du flux sont bloqués, ou détruits sans être transmis, ce qui préserve complètement le nœud client récepteur de toute nuisance que ce flux lui causerait.
Selon un aspect du procédé de priorisation d’un flux de paquets, le procédé comprend en outre l'émission du message comprenant la valeur attendue du paramètre de protection, vers un nœud routeur voisin du nœud routeur connecté au nœud récepteur. Grâce à cet aspect, la priorisation des flux est rendue possible au niveau d'un nœud voisin du nœud routeur connecté au nœud client, de préférence en amont du flux. Cela est avantageux dans le cas d'une attaque DDoS, où les flux attaquant arrivent sur le dernier nœud routeur en provenance de plusieurs nœuds routeurs immédiatement voisins. La charge de prioriser les flux est ainsi mieux répartie dans le réseau de routeurs. L'émission du message, qui est équivalent à l'émission d'une commande de priorisation, peut n'être déclenchée que sur atteinte d'un seuil, par exemple lorsque le volume de données reçues par le nœud routeur ou sur son interface amont atteint un seuil au-delà duquel le fonctionnement du nœud routeur ou de son interface amont est mis en danger.
Selon un aspect du procédé de protection et du procédé de priorisation d’un flux de paquets, le paramètre de protection est inclus dans l'adresse IPv6 de destination des paquets du flux.
Grâce à cet aspect, une particularité existante des adresses en IPv6 est exploitée avantageusement. En effet les derniers bits d’une adresse IPv6, par exemple les 64 derniers bits, peuvent être déterminés et modifiés à volonté par l'utilisateur du flux, par exemple le client utilisateur des nœuds émetteur et récepteur, client du réseau opérateur formé par les nœuds routeurs, sans impacter le routage des paquets vers leur destination finale. Ces 64 bits représentent un très grand nombre de valeurs possibles pour le paramètre de protection, ce qui rend leur découverte par un attaquant difficile voire impossible.
Selon un aspect du procédé de protection et du procédé de priorisation d’un flux de paquets, le flux est un tunnel IPsec ou un tunnel IP.
Grâce à cet aspect, la solution de protection couvre les flux les plus courants et les plus importants car typiquement à destinations de plusieurs destinataires. De plus, certains paramètres existants spécifiques de ces tunnels peuvent avantageusement être utilisés en tant que paramètre de protection selon l'invention. Des exemples de tunnel IP sont L2TP, GRE, UDP, SRv6 (Segment Routing IPv6). Selon un aspect du procédé de protection et du procédé de priorisation d’un flux de paquets, l'au moins un champ comprenant le paramètre de protection est un ou plusieurs des champs d'une liste comprenant:
• "Security Parameters Index" (SPI) de IPsec,
• "Protocol" de IPv4,
• "Next Header" de IPv6,
• "Flow Label" de IPv6,
• adresse IP source, ou adresse IP destination, ou port source, ou port destination, de IPv4 ou IPv6.
• "Key" de GRE,
• Segment List, ou Segment List [n], ou Tag, ou HMAC TLV de Segment Routing IPv6 (SRv6).
Grâce à cet aspect, le flux reçu transitant par le nœud routeur peut être traité en fonction de plusieurs paramètres de protection, ce qui représente une combinaison plus difficile à découvrir par un attaquant, tout en fournissant plus de flexibilité à l’émetteur/récepteur du flux pour adapter la solution à ses cas d’usage. L’utilisation d’un paramètre spécifique à un contexte (tel que SPI, spécifique à IPsec) donne également une meilleure protection qu’un paramètre présent dans les tous paquets, quel que soit le contexte (tel que l'adresse IP ou le port), car il faut que l’attaquant découvre aussi le contexte (tel que le type de tunnel qu'utilise le flux).
Selon un aspect du procédé de protection et du procédé de priorisation d’un flux de paquets, le message comprenant la valeur attendue du paramètre de protection est un message d'un des protocoles suivants:
• BGP Flow Spec,
• NETCONF,
• RESTCONF,
• En ligne de commande (CLI: Command Line Interface),
• SNMP,
• API REST, API.
Grâce à cet aspect, le procédé selon l'invention s'insère dans une architecture réseau existante en réutilisant un protocole de communication déjà utilisé par des nœuds routeurs.
L'invention concerne aussi un dispositif de protection d’un flux de paquets dans un réseau composé de nœuds routeurs de paquets, et de nœuds émetteur et récepteur du flux, le nœud récepteur étant connecté à un nœud routeur traitant le routage d'un paquet à destination du nœud récepteur en fonction d'une valeur attendue d'un paramètre de protection compris dans au moins un champ d'un paquet du flux, le dispositif étant associé au nœud récepteur et comprenant un récepteur, un émetteur, un processeur et une mémoire couplée au processeur avec des instructions destinées à être exécutées par le processeur pour :
• l'émission d'un message comprenant la valeur attendue du paramètre de protection, à destination du nœud routeur connecté au nœud récepteur.
Ce dispositif, apte à mettre en œuvre dans tous ses modes de réalisation le procédé de protection de flux qui vient d'être décrit, est destiné à être mis en œuvre dans un équipement du sous-réseau composés des nœuds émetteur et récepteur du flux, aussi appelé réseau client. Il peut faire partie du nœud récepteur ou du nœud émetteur, ou faire partie d'un équipement de gestion du réseau client, distinct des nœuds émetteur ou récepteur du flux, par exemple un nœud contrôleur SD-WAN si le réseau client est de type SD-WAN. Dans tous les cas ce dispositif est associé au nœud récepteur, c’est- à-fait partie du même domaine administratif.
L'invention concerne aussi un dispositif de priorisation d’un flux de paquets dans un réseau composé de nœuds routeurs de paquets, et de nœuds émetteur et récepteur du flux, le nœud récepteur étant connecté à un nœud routeur traitant le routage d'un paquet à destination du nœud récepteur en fonction d'une valeur attendue d'un paramètre de protection compris dans au moins un champ d'un paquet du flux, le dispositif étant mis en œuvre dans le nœud routeur connecté au nœud récepteur et comprenant un récepteur, un émetteur, un processeur et une mémoire couplée au processeur avec des instructions destinées à être exécutées par le processeur pour :
• la réception d'un message comprenant la valeur attendue du paramètre de protection, en provenance d'un dispositif associé au nœud récepteur,
• la priorisation des paquets comprenant la valeur attendue du paramètre de protection.
Ce dispositif, apte à mettre en œuvre dans tous ses modes de réalisation le procédé de priorisation de flux qui vient d'être décrit, est destiné à être mis en œuvre dans un nœud du sous-réseau composé des nœuds routeurs, aussi appelé réseau opérateur. Plus précisément ce dispositif fait partie du nœud routeur connecté au nœud récepteur du réseau client.
L'invention concerne aussi un programme d'ordinateur comprenant des instructions qui, lorsque ces instructions sont exécutées par un processeur, conduisent celui-ci à mettre en œuvre les étapes du procédé de protection, qui vient d'être décrit.
L'invention concerne aussi un programme d'ordinateur comprenant des instructions qui, lorsque ces instructions sont exécutées par un processeur, conduisent celui-ci à mettre en œuvre les étapes du procédé de priorisation, qui vient d'être décrit.
L’invention vise aussi un support d'informations lisible par un dispositif de protection, et comportant des instructions d'un programme d'ordinateur tel que mentionné ci-dessus. L’invention vise aussi un support d'informations lisible par un dispositif de priorisation, et comportant des instructions d'un programme d'ordinateur tel que mentionné ci-dessus.
Les programmes mentionnés ci-dessus peuvent 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.
Les supports d'informations mentionnés ci-dessus peuvent être n'importe quelle entité ou dispositif capable de stocker le programme. Par exemple, un 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.
Un tel moyen de stockage peut par exemple être un disque dur, une mémoire flash, etc. D'autre part, un support d'informations peut être un support transmissible tel qu'un signal électrique ou optique, qui peut être acheminé via un câble électrique ou optique, par radio ou par d'autres moyens. Un programme selon l'invention peut être en particulier téléchargé sur un réseau de type Internet.
Alternativement, un support d'informations 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 en question.
4. Présentation des figures
D'autres avantages et caractéristiques de l'invention apparaitront plus clairement à la lecture de la description suivante d'un mode de réalisation particulier de l'invention, donné à titre de simple exemple illustratif et non limitatif, et des dessins annexés, parmi lesquels :
[Fig 1] la figure 1 représente, de façon schématique, un réseau comprenant des nœuds routeurs et des nœuds clients conformes à l’invention, dans un mode particulier de réalisation,
[Fig 2] la figure 2 présente un exemple de structure d'un dispositif de protection, mis en œuvre côté réseau client, selon des aspects de l'invention,
[Fig 3] la figure 3 présente un exemple de structure d'un dispositif de priorisation, mis en œuvre côté réseau de routeurs, selon des aspects de l'invention.
5. Description détaillée d'au moins un mode de réalisation de l'invention
La figure 1 représente, de façon schématique, un réseau comprenant des nœuds routeurs et des nœuds clients conformes à l’invention, dans un mode particulier de réalisation. Le réseau N1 comprend un sous-réseau N2 composé de nœuds routeurs R1 à R4 gérés par un opérateur de télécommunications, appelé réseau opérateur, et un sous-réseau N3 composé de nœuds clients C1 à C3 gérés par une entité tierce indépendante de l'opérateur, appelé réseau client. Le réseau opérateur N2 est par exemple un réseau IP/MPLS, aussi dit réseau de transport. Le réseau client N3 peut être de type VPN, SD- WAN, etc.
Dans un mode particulier de réalisation, un flux F1 est établi entre le nœud client C1 et le nœud client C3. Le nœud client C1 est connecté au nœud routeur R1 , le nœud client C3 est connecté au nœud routeur R3, et le flux F1 émis par le nœud C1 à destination du nœud client C3 emprunte une route B1 commençant au nœud client C1 , passant par les nœuds routeurs R1 , R2 et R3, et se terminant au nœud client C3.
Le nœud client C3 peut recevoir d'autres flux en provenance d'autres sources, comme par exemple un flux F2 émis par la source A1 , empruntant ou étant destiné à emprunter une route B2 ayant en commun avec la route B1 le nœud routeur R3 et le nœud client C3. La source A1 peut être tout type d'équipement apte à se connecter à un nœud routeur du réseau opérateur N2. Par simplicité la source A1 est illustrée par un nuage figurant en dehors des réseaux N2 ou N3, mais elle peut faire partie ou non du réseau opérateur N2, ou faire partie ou non du réseau client N3.
Un problème survient lorsque le flux F2 émis par la source A1 n'est pas un flux attendu par le nœud client C3 et présente un volume de données susceptible de dégrader le fonctionnement du nœud client C3. Ce problème est souvent nommé dans la littérature attaque par déni de service, ou attaque DoS (Denial of Service, en anglais). La source A1 , illustrée dans la figure 1 comme étant unique par simplicité, peut aussi être multiple, ce qui aggrave le problème. On parle alors d'attaque DoS distribuée, ou attaque DDoS (Distributed DoS, en anglais). Les multiples flux émis par la source multiple A1 , autrement dit l'attaquant DDoS, peuvent emprunter des routes différentes mais ils aboutissent tous sur le nœud routeur R3 qui est le dernier nœud routeur avant le nœud attaqué qui est le nœud client C3.
Afin de repousser une telle attaque, les flux arrivant sur le nœud routeur R3 et qui ne sont pas légitimement attendus par le nœud client C3 et risquent de lui nuire, doivent être filtrés, c’est-à-dire soit bloqués, soit réduits dans leur volume ou dans leur débit, soit abaissés en terme de priorité (QoS). Abaisser la priorité des flux est particulièrement avantageux s'il est important de laisser passer certains flux légitimes mais non prévisibles venant de l'Internet, tant qu'une attaque n'est pas en cours.
Selon l'invention, en remplacement ou en complément de ce filtrage, les flux arrivant sur le nœud routeur R3, et qui sont légitimement attendus par le nœud client C3, sont priorisés par rapport aux autres flux.
Dans ce but, selon l'invention, un flux doit pouvoir fournir au nœud routeur R3 un paramètre particulier avant d'être transmis par le nœud routeur R3 à sa destination qui est le nœud client C3. Ce paramètre de protection, comparable à une signature, doit être connu à l'avance par le nœud routeur R3. Il est communiqué dans une signalisation en provenance d'un dispositif du réseau client N3 à destination d'une entité du réseau de transport N2. Selon l'invention, plusieurs méthodes alternatives permettent au nœud routeur R3 d'obtenir les informations nécessaires, dont le paramètre de protection.
Le nœud routeur R3 doit pouvoir identifier le nœud client et les flux à protéger. Pour ce faire, la signalisation comprend soit l'adresse de destination des flux, qui correspond à l'adresse IP du nœud client C3, soit une autre information permettant d'identifier le nœud client C3, tel qu'un numéro de port ou d'interface, un nom de domaine (DNS), un certificat cryptographique, etc. Utiliser une adresse IPv6 est particulièrement avantageux car cette adresse est codée sur un nombre de bits suffisamment grand pour aussi y inclure le paramètre de protection. Si la signalisation est émise directement par le nœud client C3, une autre façon pour le nœud routeur R3 d'identifier le nœud client C3 est au travers de l'identifiant de l'émetteur de la signalisation, comme par exemple l'adresse IP d'origine d'un paquet de la signalisation ou l’interface d’arrivée de la signalisation. Plusieurs protocoles de signalisation vers le nœud routeur R3 peuvent être utilisés :
Un protocole de signalisation de flux comme BGP FlowSpec (RFC5575 et sa révision draft-ietf-idr-rfc5575bis « Dissemination of Flow Specification Rules ») et ses extensions;
Un protocole de configuration tel que NETCONF (RFC 6241 « Network Configuration Protocol (NETCONF) », RESTCONF (RFC 8040 « RESTCONF Protocol », CLI (Command Line Interface) ou SNMP;
Une interface propriétaire de type API (Application Programmation Interface).
La source de la signalisation peut être :
Le nœud client C1 ou le nœud client C3 ;
Un contrôleur de communication des flux clients (par exemple un contrôleur SD- WAN), dans le réseau N3.
La signalisation peut transiter par un contrôleur de routeurs du réseau opérateur N2, dans les cas où par exemple les routeurs du réseau N2 ne sont pas aptes à recevoir directement du réseau N3 des messages de signalisation. Ce contrôleur agit alors comme équipement intermédiaire qui adapte le protocole ou le format du message de signalisation avant de le réémettre vers un routeur.
Dans un mode de réalisation, le nœud client C1 envoie son flux avec le paramètre de protection de son choix (ou du choix du nœud client C3). Le nœud routeur R1 surveille les entêtes de nouveaux flux provenant du nœud client C1. Le nœud routeur R1 découvre le paramètre de protection et le signale au noud routeur R3, directement ou indirectement via un contrôleur de routeurs du réseau opérateur N2.
Dans un mode de réalisation, après avoir reçu le paramètre de protection, le nœud routeur R3 le communique aux nœuds routeurs qui lui sont immédiatement voisins, c’est- à-dire les nœuds routeurs R2 et R4. En effet tous les flux destinés au nœud client C3 passent obligatoirement par un des nœuds routeurs immédiatement en amont du nœud routeur R3. Ainsi, la charge de traiter selon l'invention (priorisation, ou priorisation avec filtrage) les flux destinés au nœud client C3 est répartie sur plusieurs nœuds routeurs plutôt que sur un seul.
Dans un mode de réalisation, la communication du paramètre de protection vers un nœud routeur amont peut être déclenchée par un nœud routeur aval lorsque le volume de flux reçus par ce routeur atteint un seuil mettant en danger le nœud aval ou le lien entre le nœud routeur amont et le nœud routeur aval. Ainsi, le nœud routeur R3 se protège en déléguant la charge des traitements (priorisation, ou priorisation avec filtrage) au nœud routeur R4, ce qui se trouve utile car c'est par ce nœud que transite le flux F2. Dans un mode de réalisation, le nœud routeur R4 peut lui aussi communiquer le code de protection vers un nœud routeur amont (non illustré dans la figure 1 ), de façon récursive. Le seuil de déclenchement de cette communication peut être fonction des capacités du nœud routeur R4 et être différent de celui du nœud routeur R3. On comprend qu'il est ainsi possible de remonter la charge de filtrer le flux F2 jusqu'au premier nœud routeur emprunté par le flux F2 dans le réseau N2. L'identification et la localisation de la source A1 peut ainsi être facilitée et l’ensemble du réseau N2 est alors dispensé de transporter le flux F2 qui non seulement est de volume important, mais est destiné à être détruit.
En plus d'être communiqué au réseau de transport N2, le paramètre de protection est également inséré dans un ou plusieurs champs des paquets du F1 avant leur émission par le nœud client C1. Dans le cas le plus simple, le paramètre de protection est inséré dans un seul champ d'un paquet, mais dans une variante de réalisation il peut être constitué de plusieurs parties qui sont réparties dans plusieurs champs d'un paquet.
Dans un mode de réalisation, le paramètre de protection est inclus dans l'adresse IPv6 de destination des paquets du flux F1 , par exemple dans les 64 dernier bits de l'adresse IPv6. Dans un mode de réalisation, le flux F1 est un tunnel IPsec et le paramètre de protection est compris dans le champ SPI (Security Parameters Index). L'avantage du champ SPI est qu'il est un champ spécifique aux tunnels IPsec, et que sa valeur peut être modifiée au besoin sans impacter le routage du flux.
Dans un mode de réalisation, le flux F1 est un tunnel IPsec et le paramètre de protection est réparti sur plusieurs champs, dont fait partie le champ SPI de préférence. Les autres champs utilisables sont : le champ Protocol (ou le champ Next Header dans le cas IPv6), le champ adresse IP source, le champ adresse IP destination, le champ port source, le champ port destination. Aussi utilisables sont certains champs de SRv6 (Segment Routing IPv6, RFC 8754), tels que par exemple Segment List, Segment List [n], Tag, HMAC TLV.
Dans un mode de réalisation où le flux n'est pas un tunnel IPsec, le champ SPI ne peut pas être utilisé mais les autres champs qui viennent d'être mentionnés sont utilisables. Le champ Key de GRE (Generic Routing Encapsulation) est aussi utilisable. D'autres champs spécifiques aux paquets IPv6 peuvent aussi être utilisés, tels que Routing Header, Destination option, ou Authentication Header.
Par sécurité et particulièrement en IPv4, il peut être préférable de répartir le paramètre de protection sur plusieurs champs dont au moins le champ Protocol, car les autres champs (adresses IP et ports) sont plus facilement découvrables par un attaquant.
En relation avec la figure 2, on présente maintenant un exemple de structure d'un dispositif de protection d'un flux de paquets, selon un aspect de l'invention.
Le dispositif 100 de protection met en œuvre le procédé de protection d'un flux de paquets, dont différents modes de réalisation viennent d'être décrits.
Un tel dispositif 100 peut être mis en œuvre dans un nœud émetteur ou récepteur du flux, ou dans un contrôleur de communication des flux clients (par exemple un contrôleur SD-WAN). Par exemple, le dispositif 100 comprend un récepteur 101 , un émetteur 102, une unité de traitement 130, équipée par exemple d'un microprocesseur pP, et pilotée par un programme d'ordinateur 110, stocké dans une mémoire 120 et mettant en œuvre le procédé de protection selon l'invention. A l’initialisation, les instructions de code du programme d’ordinateur 110 sont par exemple chargées dans une mémoire RAM, avant d’être exécutées par le processeur de l’unité de traitement 130.
Une telle mémoire 120, un tel processeur de l’unité de traitement 130, un tel récepteur 101 et un tel émetteur 102 sont aptes à, et configurés pour :
• l'émission d'un message comprenant la valeur attendue du paramètre de protection, à destination du nœud routeur connecté au nœud récepteur ou destinataire du flux.
Avantageusement, ils sont également aptes à, et configurés pour :
• la réémission d'un nouveau message avec une nouvelle valeur du paramètre de protection, après expiration d'une période définie.
En relation avec la figure 3, on présente maintenant un exemple de structure d'un dispositif de priorisation d'un flux de paquets, selon un aspect de l'invention.
Le dispositif 200 de priorisation met en œuvre le procédé de filtrage d'un flux de paquets, dont différents modes de réalisation viennent d'être décrits.
Un tel dispositif 200 peut être mis en œuvre dans un nœud routeur de flux de paquets, par exemple le nœud routeur connecté à un nœud client destinataire des flux.
Par exemple, le dispositif 200 comprend un récepteur 201 , un émetteur 202, une unité de traitement 230, équipée par exemple d'un microprocesseur pP, et pilotée par un programme d'ordinateur 210, stocké dans une mémoire 220 et mettant en œuvre le procédé de priorisation d'un flux de paquets selon l'invention. A l’initialisation, les instructions de code du programme d’ordinateur 210 sont par exemple chargées dans une mémoire RAM, avant d’être exécutées par le processeur de l’unité de traitement 230. Une telle mémoire 220, un tel processeur de l’unité de traitement 230, un tel récepteur 201 et un tel émetteur 202 sont aptes à, et configurés pour :
• la réception d'un message comprenant la valeur attendue du paramètre de protection, en provenance d'un dispositif associé au nœud récepteur, la priorisation des paquets comprenant la valeur attendue du paramètre de protection.
Avantageusement, ils sont également aptes à, et configurés pour :
• le filtrage des paquets ne comprenant pas la valeur attendue du paramètre de protection,
• l'émission du message comprenant la valeur attendue du paramètre de protection, vers un nœud routeur voisin.
Les entités décrites et comprises dans les dispositifs décrits en relation avec les figures 2 et 3 peuvent être matérielles ou logicielles. Les figures 2 et 3 illustrent seulement une manière particulière, parmi plusieurs possibles, de réaliser l’algorithme détaillé ci-dessus, en relation avec la figure 1 . En effet, la technique de l’invention se réalise indifféremment sur une machine de calcul reprogrammable (un ordinateur PC, un processeur DSP ou un microcontrôleur) exécutant un programme comprenant une séquence d’instructions, ou sur une machine de calcul dédiée (par exemple un ensemble de portes logiques comme un FPGA ou un ASIC, ou tout autre module matériel).
Dans le cas où l’invention est implantée sur une machine de calcul reprogrammable, le programme correspondant (c'est-à-dire la séquence d’instructions) pourra être stocké dans un médium de stockage amovible (tel que par exemple une clé USB, une disquette, un CD-ROM ou un DVD-ROM) ou non, ce médium de stockage étant lisible partiellement ou totalement par un ordinateur ou un processeur.

Claims

REVENDICATIONS
1. Procédé de priorisation d’un flux (F1 ) de paquets dans un réseau composé de nœuds routeurs (R1-R4) de paquets, et de nœuds (C1-C3) émetteur et récepteur du flux, le nœud récepteur (C3) étant connecté à un nœud routeur (R3) traitant le routage d'un paquet à destination du nœud récepteur en fonction d'une valeur attendue d'un paramètre de protection compris dans au moins un champ d'un paquet du flux, le procédé étant mis en œuvre par le nœud routeur (R3) connecté au nœud récepteur (C3) et comprenant :
• la réception d'un message comprenant la valeur attendue du paramètre de protection, en provenance d'un dispositif associé au nœud récepteur (C3),
• la priorisation des paquets comprenant la valeur attendue du paramètre de protection.
2. Procédé de priorisation selon la revendication précédente, où la priorisation comprend une mise des paquets dans une file d'attente ayant accès à une ou plusieurs interfaces de sortie du nœud routeur (R3), l'accès étant prioritaire sur au moins une autre file d'attente.
3. Procédé de priorisation selon les revendications précédentes, comprenant en outre le filtrage des paquets ne comprenant pas la valeur attendue du paramètre de protection.
4. Procédé de priorisation selon la revendication précédente, où le filtrage comprend un blocage des paquets, ou une destruction des paquets, ou un abaissement de la priorité des paquets.
5. Procédé de priorisation selon l'une des revendications précédentes, comprenant en outre l'émission du message comprenant la valeur attendue du paramètre de protection, vers un nœud routeur voisin (R2, R4) du nœud routeur (R3) connecté au nœud récepteur (C3).
6. Procédé selon l'une des revendications précédentes, où le paramètre de protection est inclus dans l'adresse IPv6 de destination des paquets du flux (F1 ).
7. Procédé selon l'une des revendications précédentes, où le flux (F1 ) est un tunnel IPsec ou un tunnel IP.
8. Procédé selon l'une des revendications précédentes, où l'au moins un champ comprenant le paramètre de protection est un ou plusieurs des champs d'une liste comprenant:
• "Security Parameters Index" (SPI) de IPsec,
• "Protocol" de IPv4,
• "Next Header" de IPv6,
• "Flow Label" de IPv6,
• adresse IP source, ou adresse IP destination, ou port source, ou port destination, de IPv4 ou IPv6.
• "Key" de GRE,
• Segment List, ou Segment List [n], ou Tag, ou HMAC TLV de Segment Routing IPv6 (SRv6).
9. Procédé selon l'une des revendications précédentes, où le message comprenant la valeur attendue du paramètre de protection est un message d'un des protocoles suivants:
• BGP Flow Spec,
• NETCONF,
• RESTCONF,
• En ligne de commande (CLI: Command Line Interface),
• SNMP,
• API REST,
• API.
10. Dispositif (200) de priorisation d’un flux (F1 ) de paquets dans un réseau (N1 ) composé de nœuds (R1-R4) routeurs de paquets, et de nœuds (C1-C3) émetteur et récepteur du flux, le nœud récepteur (C3) étant connecté à un nœud routeur (R3) traitant le routage d'un paquet à destination du nœud récepteur en fonction d'une valeur attendue d'un paramètre de protection compris dans au moins un champ d'un paquet du flux, le dispositif étant mis en œuvre dans le nœud routeur (R3) connecté au nœud récepteur (C3) et comprenant un récepteur (201 ), un émetteur (202), un processeur (230) et une mémoire (220) couplée au processeur avec des instructions destinées à être exécutées par le processeur pour :
• la réception d'un message comprenant la valeur attendue du paramètre de protection, en provenance d'un dispositif (100) associé au nœud récepteur (C3),
• la priorisation des paquets comprenant la valeur attendue du paramètre de protection.
11. Programme d'ordinateur (210), comprenant des instructions qui, lorsque ces instructions sont exécutées par un processeur, conduisent celui-ci à mettre en œuvre les étapes du procédé de priorisation selon la revendication 1.
12. Support d'informations lisible par un dispositif de priorisation (200), et comportant des instructions d'un programme d'ordinateur (210) conforme à la revendication 11.
PCT/FR2021/051828 2020-10-22 2021-10-20 Procédé et dispositif de priorisation de flux de paquets WO2022084624A1 (fr)

Priority Applications (2)

Application Number Priority Date Filing Date Title
US18/249,844 US20230388270A1 (en) 2020-10-22 2021-10-20 Method and device for prioritising packet flows
EP21806788.2A EP4232926A1 (fr) 2020-10-22 2021-10-20 Procédé et dispositif de priorisation de flux de paquets

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FRFR2010858 2020-10-22
FR2010858A FR3117296A1 (fr) 2020-10-22 2020-10-22 Procédé et dispositif de priorisation de flux de paquets

Publications (1)

Publication Number Publication Date
WO2022084624A1 true WO2022084624A1 (fr) 2022-04-28

Family

ID=74553944

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/FR2021/051828 WO2022084624A1 (fr) 2020-10-22 2021-10-20 Procédé et dispositif de priorisation de flux de paquets

Country Status (4)

Country Link
US (1) US20230388270A1 (fr)
EP (1) EP4232926A1 (fr)
FR (1) FR3117296A1 (fr)
WO (1) WO2022084624A1 (fr)

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20060010389A1 (en) * 2004-07-09 2006-01-12 International Business Machines Corporation Identifying a distributed denial of service (DDoS) attack within a network and defending against such an attack
US20130269031A1 (en) * 2012-02-20 2013-10-10 Alaxala Networks Corporation Network system, network relay method, and network relay device

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20060010389A1 (en) * 2004-07-09 2006-01-12 International Business Machines Corporation Identifying a distributed denial of service (DDoS) attack within a network and defending against such an attack
US20130269031A1 (en) * 2012-02-20 2013-10-10 Alaxala Networks Corporation Network system, network relay method, and network relay device

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
PIERRE-EDOUARD FABRE: "Using network resources to mitigate volumetric DDoS", 13 December 2018 (2018-12-13), XP055721332, Retrieved from the Internet <URL:https://tel.archives-ouvertes.fr/tel-01983197/document> [retrieved on 20210614] *

Also Published As

Publication number Publication date
FR3117296A1 (fr) 2022-06-10
US20230388270A1 (en) 2023-11-30
EP4232926A1 (fr) 2023-08-30

Similar Documents

Publication Publication Date Title
EP3476095B1 (fr) Procédé de communication udp via des chemins multiples entre deux terminaux
JP4955107B2 (ja) Ｉｐネットワーク内のトラフィックを分類するための方法およびユニット
WO2019002754A1 (fr) Procédé de communication quic via des chemins multiples
EP3476096B1 (fr) Procédé de communication udp via des chemins multiples entre deux terminaux
EP3318023B1 (fr) Procédé d&#39;optimisation de la charge d&#39;un concentrateur de connexions réseau
US9887974B2 (en) Method for network communication past encryption devices
EP3284224B1 (fr) Procédé d&#39;émulation dune connexion à chemins multiples
WO2020260813A1 (fr) Procédé de gestion d&#39;une communication entre terminaux dans un réseau de communication, et dispositifs pour la mise en oeuvre du procédé
Gheorghe Designing and Implementing Linux Firewalls with QoS using netfilter, iproute2, NAT and l7-filter
US20220201044A1 (en) Policing of data
WO2019211548A1 (fr) Procédé d&#39;envoi d&#39;une information et de réception d&#39;une information pour la gestion de réputation d&#39;une ressource ip
WO2022084624A1 (fr) Procédé et dispositif de priorisation de flux de paquets
EP4233334A1 (fr) Procédés et dispositifs de protection de flux de paquets
EP3949287B1 (fr) Passerelle et procédé de différentiation de trafic émis par la passerelle, dispositif et procédé gestion du trafic
WO2015197978A1 (fr) Procede de protection d&#39;un routeur contre des attaques
EP2579545A1 (fr) Méthode d&#39;attribution d&#39;une adresse réseau publique à un équipement disposant d&#39;une adresse réseau privée
FR3044195A1 (fr) Procede et dispositif de traitement d&#39;une annonce non legitime d&#39;un bloc d&#39;adresses ip
EP4128701A1 (fr) Procédé de gestion de communications et dispositifs associés
Dobbins Defending the Network: Mitigating Attacks
Guiton of the Thesis: A Rate-Limiting System to Mitigate Denial of Service Attacks
FR2947123A1 (fr) Procedes de transmission entre un emetteur et un recepteur, et un recepteur, avec transmission d&#39;une donnee additionnelle en fonction de la longueur d&#39;au moins deux paquets, emetteur et recepteur correspondants

Legal Events

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

Ref document number: 21806788

Country of ref document: EP

Kind code of ref document: A1

WWE Wipo information: entry into national phase

Ref document number: 18249844

Country of ref document: US

NENP Non-entry into the national phase

Ref country code: DE

ENP Entry into the national phase

Ref document number: 2021806788

Country of ref document: EP

Effective date: 20230522