EP3942772A1 - Procédé de sécurisation de la transmission d'au moins un paquet de données le long d'un chemin de données d'un réseau de télécommunications, produit programme d'ordinateur et dispositif correspondants - Google Patents

Procédé de sécurisation de la transmission d'au moins un paquet de données le long d'un chemin de données d'un réseau de télécommunications, produit programme d'ordinateur et dispositif correspondants

Info

Publication number
EP3942772A1
EP3942772A1 EP20726188.4A EP20726188A EP3942772A1 EP 3942772 A1 EP3942772 A1 EP 3942772A1 EP 20726188 A EP20726188 A EP 20726188A EP 3942772 A1 EP3942772 A1 EP 3942772A1
Authority
EP
European Patent Office
Prior art keywords
delay
data path
wandering
data
data packet
Prior art date
Legal status (The legal status 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 status listed.)
Pending
Application number
EP20726188.4A
Other languages
German (de)
English (en)
Inventor
Emile Stephan
Gaël FROMENTOUX
Frédéric FIEAU
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Orange SA
Original Assignee
Orange SA
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 SA filed Critical Orange SA
Publication of EP3942772A1 publication Critical patent/EP3942772A1/fr
Pending legal-status Critical Current

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/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
    • 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/1466—Active attacks involving interception, injection, modification, spoofing of data unit addresses, e.g. hijacking, packet injection or TCP sequence number attacks
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00—Routing or path finding of packets in data switching networks
    • H04L45/42—Centralised routing
    • 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
    • H04L63/1416—Event detection, e.g. attack signature detection
    • 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
    • H04L63/1425—Traffic logging, e.g. anomaly detection
    • 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/20—Network architectures or network communication protocols for network security for managing network security; network security policies in general
    • 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
    • H04W12/121—Wireless intrusion detection systems [WIDS]; Wireless intrusion prevention systems [WIPS]
    • H04W12/122—Counter-measures against attacks; Protection against rogue devices
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/60—Context-dependent security
    • H04W12/61—Time-dependent

Definitions

  • TITLE Method for securing the transmission of at least one data packet along a data path of a telecommunications network, corresponding computer program product and device.
  • the field of the invention is that of the implementation of telecommunications networks.
  • the invention relates more particularly to securing the transmission of data in such telecommunications networks.
  • the invention has many applications, in particular, but not exclusively, in the field of telecommunications networks of last generations or of future generations.
  • a method for securing the transmission of at least one data packet along a data path of a telecommunications network.
  • a security device performs the following steps:
  • the invention proposes a new and inventive solution for securing the transmission of data in a telecommunications network.
  • obtaining a wandering delay associated with a packet having followed a given data path makes it possible to determine whether the delay that it actually took to travel the path in question (ie the end transit delay - effective end along the data path, the path extending between any two nodes of the network) is different from the expected delay, for example taking into account the known constraints of the physical implementation of the data path, to travel the path in question (ie the expected end-to-end transit delay along the data path). If this is the case, it can be inferred that the path in question has been changed, for example when a third-party device which is not one of the trusted devices has been added to the data path, or if part of the hardware functions located along the path has been deported in a virtualized manner.
  • obtaining the wandering delay corresponds to a calculation of the wandering delay comprising obtaining the effective end-to-end transit delay by:
  • pre-measure end-to-end transit delay along the data path or by preliminary measurement of a half value of the round trip transit delay along the data path.
  • the total round trip transit times and on the downstream and upstream segments are obtained by observing the change in the value of the “spinbit” according to this protocol. .
  • the effective end-to-end transit delays relating to the observation point are easily obtained.
  • the data path passes through at least one node of the network.
  • the calculation of the wandering delay comprises obtaining a node crossing delay for said at least one data packet.
  • the expected end-to-end transit delay is a function of said at least one crossing delay.
  • the data path passes through at least two nodes of the network. For each pair of nodes among the at least two nodes, calculating the roaming delay includes obtaining a propagation delay of said at least one data packet along the data path between the nodes of the node pair.
  • the expected end-to-end transit delay is a function of said at least one propagation delay.
  • the propagation delay is a physical parameter that is generally available in the equipment or during link deployments.
  • the expected end-to-end transit delay is more precise because it also takes into account the delay on the interconnections between the nodes.
  • the wandering delay is calculated as a function of the effective end-to-end transit delay from which is subtracted said at least one crossing delay and / or said at least one propagation delay.
  • the data path extends between a first and a second network node of the network, the security device being housed in the second network node. Said at least one crossing delay is obtained from at least one parameter conveyed within said at least one data packet.
  • the crossing delays are easily conveyed along the data path to the device calculating the wandering delay.
  • said at least one securing action belongs to the group comprising:
  • a specific securing action can be implemented by a dedicated device
  • a very low wander network can be formed based on a selection only of the roads whose wander is less than a predetermined value.
  • the securing device is not located along the data path.
  • the crossing delay is received from said at least one node via at least one other data packet distinct from said at least one data packet.
  • the crossing delay is received in encrypted form, the securing device and said at least one node sharing the knowledge of minus an encryption information.
  • the transfer of the crossing delay from the node (s) to the securing device is secure.
  • the encryption information can use some shared parameters of the PoT protocol.
  • said at least one piece of encryption information is obtained by said at least one node via said at least data packet.
  • said at least one securing action belongs to the group comprising:
  • obtaining the wandering delay corresponds to receiving, via another data packet distinct from said at least one data packet, of the wandering delay from another device located along the data path.
  • Said at least one securing action belongs to the group comprising:
  • a specific securing action can be implemented by a dedicated device
  • the securing method is implemented successively for a plurality of data paths of the network.
  • the invention also relates to a computer program comprising program code instructions for implementing the method as described above, according to any one of its various embodiments, when it is executed on a computer.
  • a device for securing the transmission of at least one data packet along a data path of a telecommunications network comprises a reprogrammable computing machine or a dedicated computing machine configured to implement the steps of the securing method according to the invention (according to any one of the various aforementioned embodiments).
  • a node of a telecommunications network comprises at least one aforementioned security device (according to any one of the various aforementioned embodiments).
  • FIG. 1 represents a data path of an autonomous domain of a telecommunications network along which the data transmission is secured by implementing a security method according to an embodiment of the invention
  • FIG. 2 represents the steps of a method for securing the transmission of data along a data path according to one embodiment of the invention
  • FIG. 3 represents an example of exchanges between entities of a telecommunications network implementing the method for securing the transmission of data according to one embodiment of the invention
  • FIG. 4 represents an example of exchanges between entities of a telecommunications network implementing the method for securing the transmission of data according to another embodiment of the invention
  • FIG. 5 represents an example of exchanges between entities of a telecommunications network implementing the method for securing the transmission of data according to yet another embodiment of the invention
  • FIG. 6 shows an example of a device structure allowing the implementation of the steps of the method of [fig. 2] according to one embodiment of the invention.
  • the general principle of the invention is based on obtaining a wandering delay of one (or more) data packets along a data path (eg which extends between two of the nodes of the network) . More particularly, the wandering delay is representative of a difference between: an effective end-to-end transit delay of the data packet along the data path (ie the delay that the packet actually took to travel the data path); and an expected end-to-end transit delay of the data packet along the data path (i.e. all or part of the known delay, eg associated with trusted nodes, that the packet is supposed to take to travel the data path ).
  • Such a metric is relevant in order to secure the transmission of data in the network and a securing action can be implemented on the basis of such a wandering delay.
  • a value of the wandering time greater than a predetermined threshold is representative of the fact that the data path taken by the data packet could have been modified, for example example when a third-party device which is not part of the trusted devices has been added to the data path, or if part of the hardware functions located along the path have been deported in a virtualized manner.
  • a user terminal UE sends a data packet to a server Serv via the data path passing through the five network nodes, NI to N5, which are here nodes. of confidence. For example, trust in the nodes NI to N5 is established by implementing the PoT mechanism.
  • a securing device 100 implements the securing method described further below in relation to the steps shown in [fig. 2] in order to secure the data path between the UE terminal and the server Serv.
  • a wandering delay representative of a difference between an effective end-to-end transit delay of one (or more) data packets along the data path and a The expected end-to-end transit delay of the data packet (s) along the data path is obtained.
  • obtaining the wandering time corresponds to a calculation of the wandering time by the device 100.
  • the device 100 obtains a time limit for crossing all or part of the trusted nodes for the data packet (s), the end-to-end transit delay expected at the node in which the device is located. device 100 being a function of the crossing time (s) in question.
  • the crossing delay is supplied by the corresponding trusted node (ie NI or N2 or N3 or N4 or N5) to the device 100 in order to determine the wandering delay.
  • each trusted node adds its own crossing delay to the value of the crossing delays of the nodes previously traversed by the packet or flow along the data path.
  • the cumulative crossing delay value thus obtained is conveyed in a predefined field of the packet or stream in question (eg in the last RESET or GOAWAY packet of a QUIC connection, or periodically in any packet of the stream, or again in a packet added to the stream such as an ICMP packet, etc.).
  • the crossing delay is included in the data packet (s) in the form of a particular field).
  • the value of the crossing delay is exported to the securing device via one (or more) packet which is not a data packet passing through the data path.
  • the value of the crossing delay is exported via a PSAMP (for “Packet SAMPling”) protocol in the case of a single packet, or IPFIX (for “Internet Protocol Flow Information Export” in English, eg netflow v9 for Cisco ® and Juniper) for the case of a flow of packets.
  • Table 1 gives examples of crossing times (taking into account, for example, processing times in the entities in question, switching, etc.) involved in the various entities represented in [fig. . 1] when known.
  • the device 100 obtains the effective end-to-end delay (i.e. between the terminal and the server).
  • the effective end-to-end delay is obtained by device 100 via the half value of the round trip delay of the data path.
  • the value of the round trip delay in question is obtained for example via the “spinbit” when the data packet is according to the QUIC protocol.
  • the effective end-to-end delay is obtained by measuring the transit delay along the data path beforehand.
  • the wandering delay can be refined in some embodiments by taking into account the propagation delay in question in the calculation of the transit delay. end-to-end expected.
  • the security device 100 is implemented not in the server Serv, but in one of the trusted nodes NI to N5. In this case, device 100 calculates the time to wander from its position along the data path.
  • the securing device does not calculate the wandering time, but receives it from a third-party device which performed the calculation.
  • the step E200 for obtaining the wandering time limit is reduced to a step for receiving the wandering time.
  • step E210 the data transmission is made secure by implementing one (or more) securing action from the wandering time obtained in step E200.
  • the security action belongs to the group comprising:
  • the first and second autonomous domains AS1 and AS2 of the network each comprise a data path connecting a user terminal UE1 or UE2 to an ASBR1 or ASBR2 border router (for “Autonomous System Border Router”) via a trusted network node of the router type R_AS1 or R_AS2.
  • ASBR1 or ASBR2 border router for “Autonomous System Border Router”
  • Other autonomous domains, indexed j and k, are also present, of which only the edge routers ASBRj and ASBRk are represented in order to interface with the other autonomous domains of the network.
  • All or part of the edge routers ASBR1, ASBR2, ASBRj, ASBRk comprises a securing device 100 'according to an embodiment different from the embodiment described above in relation to [FIG. 1] More particularly, the securing device 100 'does not calculate the wandering time, but receives it from a third party device which has previously performed the calculation. For example the device 100 'included in the edge router ASBR1 receives (arrow 300_1) the wandering delay sent by the network node R_AS1 which, for its part, implements the method according to the embodiment described above in relation with [fig. 1] (e.g. the network node R_AS1 comprises a securing device 100 as described above).
  • the edge routers ASBR1, ASBR2, ASBRj, ASBRk can receive the wandering times of the various data paths, for example when the securing method is implemented successively for a plurality of data paths of the network. Such reception is done for example via information according to an IGP protocol (for “Interior gateway protocol”).
  • the edge routers ASBR1, ASBR2, ASBRj, ASBRk aggregate the wandering delays of the data paths for which they receive such wandering delays and insert them as metrics in an EGP protocol (eg according to the BGP protocol) intended for other autonomous domains (arrows 300_3).
  • EGP protocol eg according to the BGP protocol
  • Such transmissions can for example take place in parallel with transmissions of “conventional” EGP information (arrows 300_4).
  • the securing action belongs to the group comprising: registration of the wandering delay in association with the data path in a routing plan of an autonomous domain the network to which the data path belongs;
  • the edge routers ASBR1, ASBR2, ASBRj, ASBRk comprise the securing device 100 according to the embodiment of [FIG. 1] In this way, the calculation of the wandering time of the data path on which a given edge router is located is carried out in the edge router in question.
  • FIG. 4 uses the elements of the embodiment of [fig. 3] Only a road reflector RR1, RR_ASj, RR_ASk (for "Route Reflector” in English) is used in the corresponding autonomous domains.
  • the security device 100 ′ is for example here included in the route reflector RR1 so as to inject the wandering times of the data paths received from the edge router ASBR1 (arrow 400_1) as metrics in the EGP (eg according to the BGP protocol).
  • the edge router ASBR1 itself calculated the wandering time associated with the data path on which it is located (eg the edge router ASBR1 includes a device 100 as illustrated in [fig. 4]) or received the wandering delay in question (calculated by a trusted node of the path in question which, for its part, comprises eg a device 100 in this case not illustrated in [fig. 4]) as well as possibly the wandering delays associated with the other paths of the autonomous domain considered.
  • the updated EGP is sent to the edge router ASBR1 (arrow 400_2) for forwarding to the other autonomous domains (arrows 300_3).
  • Such transmissions can for example take place in parallel with transmissions of “conventional” EGP information (arrows 300_4).
  • the security device 100 "calculates the wandering delay on the basis of information (eg the crossing delays) which are transmitted to it by a means other than via the data packet (s).
  • the data packet (or packets) passing along the data path for which the wandering delay is to be obtained does not convey the crossing delays (“out-of-band” embodiment mentioned above).
  • the security device 100 is located here in a collector Coll of the IPFIX type.
  • device 100 is located in a trusted node which is not located on the data path to be secured.
  • the securing device 100 "receives the crossing delay (s) from a corresponding trusted node NI, N2, N3, N5, N6 via one (or more) other data packet distinct from the (or des) data packet transiting on a data path for which the securing device 100 "will calculate the wandering time.
  • the controller configures (arrows 500_1) in addition the level of aggregation of the flow and the address of the collector Coll in each node NI, N2, N3, N5, N6.
  • the Contr controller also configures the level of aggregation of the flow and the characteristics of the connection with the Coll collector (address, keys, etc.).
  • the data packets transport the two parameters "in-band" (i.e. in a data field which they themselves transport):
  • PoT partial sum of the shared secret that the nodes NI, N2, N3, N5, N6 calculate (the constant of the polynomial POLY1 according to PoT).
  • the securing device 100 "calculates the wandering delay on the basis of information (eg the crossing delays) which are not transmitted to it via the data packet (s) passing along the data path for which we want to calculate the wandering delay (the aforementioned “out-of-band” case).
  • the nodes NI, N2, N3, N5, N6 do not insert their crossing delay in the data packets transiting on the data path in question, an NI, N2, N3, N5 or N6 cannot therefore calculate a wander delay.
  • the Contr controller activates the PoT protocol on the NI path to N5 in NI, N2 and N5. More particularly, the Controller Contr configures (arrows 500_1) the common secret POLY2 and the secret of each node NI, N2, N5 of the path (xi, yi) at the level of each of the nodes in question, as well as of the expected result at the level of the last node of the path, here N5. N5 is therefore the only one (after the Contr controller) to know the expected PoT measurement (aka the constant of POLY1). Then each node protects its crossing delay value using at least one of the PoT parameters known or calculable by the controller Contr, for example POLY1, POLY2, RND and the secret of each node (xi, yi). For example. This allows :
  • each node NI, N2, N3, N5 or N6 synchronizes the export of the IPFIX ticket on the rising edges of the "spinbits" QUIC packets and adds the half effective round trip transit time measurements obtained in the ticket. This does two things:
  • each node NI, N2, N3, N5 or N6 exports (arrows 500_2) to the collector Coll a ticket describing the same sequence of data packets. This increases the precision of the comparison and the aggregation of the crossing times;
  • the half effective round trip transit time obtained, in particular at node N5 allows a very precise calculation of the wandering delay.
  • An example of a ticket format is:
  • the device 100 "of the collector Coll receives the crossing times from the various nodes NI, N2, N3, N5, N6. It decrypts them using the" decryption keys "received from the controller Contr during configuration as described above. (In other words, the device 100 "decrypts (or decrypts) the crossing times of the various nodes NI, N2, N3, N5, N6 on the basis of encryption information which has been obtained by the various nodes in question NI, N2, N3, N5, N6 via the data packet (s) passing along the data path considered. Such encryption information is used by the various nodes in question to encrypt (or encrypt) their delay respective crossing).
  • the device 100 "groups together the crossing times received from the various nodes NI, N2, N3, N5, N6 by flow of data packets according to the aggregation flows also received from the controller Contr during configuration.
  • the device 100 calculates a delay d 'wandering for the data path corresponding to the requested aggregation.
  • the device 100 "groups the results together in a wandering delay matrix.
  • the entries in the matrix correspond to the level of aggregation of the chosen stream (host, network, system autonomous).
  • the device 100 ′′ allows access to the matrix using, for example, the ALTO protocol (for “Application-Layer Traffic Optimization”).
  • the security device 100 ′′ measures the variation in wandering time. It signals an excessive increase as a possible attack of a path node on the packet flow.
  • the securing device 100 "transmits the wandering delay (s) to at least one other device included in a node which is not located along the data path for implementation of another securing action (eg an entry by a third party device of the wandering delay (s) in association with the data path in a routing plan).
  • another securing action eg an entry by a third party device of the wandering delay (s) in association with the data path in a routing plan.
  • the securing device 100 ′′ transmits the wandering delay (s) to a route reflector RR (eg the route reflector RR comprises a device 100 ′ as illustrated in [fig. 5]) so as to inject the wander delay (s) of the calculated or received data paths (arrow 500_3) as metrics in the EGP (eg according to the BGP protocol).
  • the updated EGP is sent back by the route reflector RR to all or part of the nodes NI, N2, N3, N5, N6 (arrow 500_4).
  • types of protection other than that implemented in the PoT protocol are used for the transmission of data (e.g. the crossing or link delay (s)) to the securing device.
  • no data protection is implemented for the transmission of the data (e.g. the crossing or link delay (s)) to the securing device.
  • the device 600 comprises a random access memory 603 (for example a RAM memory), a processing unit 602 equipped for example with a processor, and controlled by a computer program stored in a read only memory 601 (for example a ROM memory or a hard disc).
  • a random access memory 603 for example a RAM memory
  • a processing unit 602 equipped for example with a processor
  • a computer program stored in a read only memory 601 (for example a ROM memory or a hard disc).
  • the code instructions of the computer program are, for example, loaded into the random access memory 603 before being executed by the processor of the processing unit 602.
  • FIG. 6 illustrates only one particular way, among several possible, of making the device 600 so that it performs certain steps of the securing method according to the invention (according to any one of the embodiments and / or variants described). s above in relation with [fig. 2]). In fact, these steps can be carried out either on a reprogrammable computing machine (a PC computer, a DSP processor or a microcontroller) executing a program comprising a sequence of instructions, or on a dedicated computing machine (for example a set of logic gates such as an FPGA or ASIC, or any other hardware module).
  • a reprogrammable computing machine a PC computer, a DSP processor or a microcontroller
  • a program comprising a sequence of instructions
  • a dedicated computing machine for example a set of logic gates such as an FPGA or 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 floppy disk, CD-ROM or 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 floppy disk, CD-ROM or DVD-ROM
  • device 600 implements any one of securing devices 100, 100 'or 100 ".
  • the device 600 implements several or all of the securing devices 100, 100 'or 100 ".
  • device 600 is included in a network node
  • NI NI

Landscapes

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

Abstract

L'invention concerne un procédé de sécurisation de la transmission d'au moins un paquet de données le long d'un chemin de données d'un réseau de télécommunications. Selon un tel procédé, un dispositif de sécurisation effectue les étapes suivantes : obtention (E200) d'un délai d'errance représentatif d'un écart entre un délai de transit de bout-en-bout effectif de l'au moins un paquet de données le long du chemin de données et un délai de transit de bout-en-bout attendu de l'au moins un paquet de données le long du chemin de données; et sécurisation (E210) de la transmission par mise en oeuvre d'au moins une action de sécurisation à partir du délai d'errance.

Description

DESCRIPTION
TITRE : Procédé de sécurisation de la transmission d'au moins un paquet de données le long d'un chemin de données d'un réseau de télécommunications, produit programme d'ordinateur et dispositif correspondants.
Domaine de l'invention
Le domaine de l'invention est celui de la mise en oeuvre des réseaux de télécommunications. L'invention se rapporte plus particulièrement à la sécurisation de la transmission de données dans de tels réseaux de télécommunications.
L'invention a de nombreuses applications, notamment, mais non exclusivement, dans le domaine des réseaux de télécommunications de dernières générations ou de générations futures.
Art antérieur et ses inconvénients
Il existe des méthodes permettant de vérifier le passage de paquets de données par une succession de noeuds d'un chemin de données d'un réseau de télécommunications. Plus particulièrement, ces méthodes sont adaptées pour vérifier le passage dans des noeuds dits de confiance, c'est-à-dire connus de l'entité en charge de la vérification des entités du réseau. A titre d'exemple, on peut citer le protocole PoT (pour « Proof of Transit » en anglais) développé par Cisco® et standardisé au sein de l'IETF (pour « Internet Engineering Task Force » en anglais).
Cependant, de telles méthodes sont la plupart du temps dites « administrées » dans le sens où elles supposent une pré-configuration des noeuds du chemin sur lequel on veut pratiquer la vérification. Dans le cas du protocole PoT, cette pré-configuration est complexe et lourde : L'algorithme de calcul est fonction de la topologie du chemin. Par exemple, la puissance du polynôme utilisé pour la vérification dépend du nombre de noeuds du chemin de données. De plus la protection de l'algorithme nécessite la détermination dynamique de polynômes associant les routeurs d'extrémités du chemin de données. De même, de telles méthodes ne supportent pas de variations sur le chemin de données et s'appliquent donc à des réseaux dont la topologie est très maîtrisée.
Par ailleurs, de telles méthodes ne permettent que de prouver le passage de paquets de données par des noeuds de confiance d'un chemin de données, mais ne disent rien sur ce qui se passe entre deux de ces noeuds de confiance.
Il existe ainsi un besoin pour une technique permettant de sécuriser la transmission de données le long d'un chemin de données en permettant d'estimer si une modification de topologie a pu se produire le long du chemin de données entre deux noeuds de confiance, e.g. si un dispositif tiers qui ne fait pas partie des dispositifs de confiance a été ajouté sur le chemin de données, ou si une partie des fonctions matérielles implantées le long du chemin ont été déportées de manière virtualisée.
Il existe également un besoin pour que la technique en question soit simple à mettre en oeuvre.
Exposé de l'invention
Dans un mode de réalisation de l'invention, il est proposé un procédé de sécurisation de la transmission d'au moins un paquet de données le long d'un chemin de données d'un réseau de télécommunications. Selon un tel procédé, un dispositif de sécurisation effectue les étapes suivantes :
obtention d'un délai d'errance représentatif d'un écart entre un délai de transit de bout- en-bout effectif dudit au moins un paquet de données le long du chemin de données et un délai de transit de bout-en-bout attendu dudit au moins un paquet de données le long du chemin de données ; et
sécurisation de la transmission par mise en oeuvre d'au moins une action de sécurisation à partir du délai d'errance.
Ainsi, l'invention propose une solution nouvelle et inventive pour sécuriser la transmission de données dans un réseau de télécommunications.
Plus particulièrement, l'obtention d'un délai d'errance associé à un paquet ayant suivi un chemin de données donné permet de déterminer si le délai qu'il a effectivement mis pour parcourir le chemin en question (i.e. le délai de transit de bout-en-bout effectif le long du chemin de données, le chemin s'étendant entre deux noeuds quelconques du réseau) est différent du délai tel qu'attendu, par exemple en tenant compte des contraintes connues d'implémentation physique du chemin de données, pour parcourir le chemin en question (i.e. le délai de transit de bout-en-bout attendu le long du chemin de données). Si tel est le cas, il peut être déduit que le chemin en question a été modifié, par exemple quand un dispositif tiers qui ne fait pas partie des dispositifs de confiance a été ajouté sur le chemin de données, ou si une partie des fonctions matérielles implantées le long du chemin a été déportée de manière virtualisée.
Selon un mode de réalisation, l'obtention du délai d'errance correspond à un calcul du délai d'errance comprenant une obtention du délai de transit de bout-en-bout effectif par :
mesure préalable du délai de transit de bout-en-bout le long du chemin de données ; ou par mesure préalable d'une demie valeur du délai de transit aller-retour le long du chemin de données.
Par exemple, lorsque le (ou les) paquet de données est formaté selon le protocole QUIC, les temps de transit aller-retour total et sur les segments aval et amont sont obtenues par observation du changement de la valeur du « spinbit » selon ce protocole. De la sorte les délais de transit effectif de bout-en-bout et relatifs au point d'observation sont obtenus de manière aisée.
Selon un mode de réalisation, le chemin de données passe par au moins un nœud du réseau. Pour chacun des nœuds, le calcul du délai d'errance comprend une obtention d'un délai de franchissement du nœud pour ledit au moins un paquet de données. Le délai de transit de bout-en-bout attendu est fonction dudit au moins un délai de franchissement.
Selon un mode de réalisation, le chemin de données passe par au moins deux nœuds du réseau. Pour chaque paire de nœuds parmi les au moins deux nœuds, le calcul du délai d'errance comprend une obtention d'un délai de propagation dudit au moins un paquet de données le long du chemin de données entre les nœuds de la paire de nœuds. Le délai de transit de bout-en-bout attendu est fonction dudit au moins un délai de propagation. Le délai de propagation est un paramètre physique qui est généralement disponible dans les équipements ou lors des déploiements des liens.
Ainsi, le délai de transit de bout-en-bout attendu est plus précis car prenant en compte également le délai sur les interconnexions entre les nœuds.
Selon un mode de réalisation, le délai d'errance est calculé comme une fonction du délai de transit de bout-en-bout effectif auquel est soustrait ledit au moins un délai de franchissement et/ou ledit au moins un délai de propagation.
Ainsi, le calcul du délai d'errance est simple et robuste.
Selon un mode de réalisation, le chemin de données s'étend entre un premier et un deuxième nœud de réseau du réseau, le dispositif de sécurisation étant logé dans le deuxième nœud de réseau. Ledit au moins un délai de franchissement est obtenu à partir d'au moins un paramètre véhiculé au sein dudit au moins un paquet de données.
Par exemple, dans le cas de plusieurs paquets de données d'une connexion du protocole QUIC, le délai de franchissement agrégé localement puis véhiculé par le dernier paquet de type RESET ou GOAWAY du flux en question. Ainsi, les délais de franchissement sont aisément véhiculés le long du chemin de données jusqu'au dispositif calculant le délai d'errance.
Selon un mode de réalisation, lorsque le dispositif de sécurisation est logé dans le deuxième nœud de réseau, ladite au moins une action de sécurisation appartient au groupe comprenant :
inscription du délai d'errance dans ledit au moins un paquet de données. Ainsi le délai d'errance reste associé au (ou aux) paquet de données quelle que soit sa destination, permettant par là-même une vérification ultérieure qu'il (ou qu'ils) a pu être altéré le long du chemin de données ;
inscription du délai d'errance en association avec le chemin de données dans un plan de routage d'un domaine autonome du réseau auquel appartient le chemin de données. Ainsi une sécurisation globale du réseau est obtenue via une cartographie des délais d'errance des chemins de données du réseau ;
destruction ou duplication pour analyse dudit au moins un paquet de données lorsque le délai d'errance est supérieur à un seuil prédéterminé ;
transmission du délai d'errance à au moins un autre dispositif inclus dans un nœud qui n'est pas situé le long du chemin de données pour mise en œuvre d'une autre action de sécurisation. Ainsi une action de sécurisation spécifique peut être mise en œuvre par un dispositif dédié ; et
une combinaison de tout ou partie des alternatives du groupe précité.
Ainsi, un réseau à très faible errance peut être constitué sur la base d'une sélection uniquement des routes dont l'errance est inférieure à une valeur prédéterminée.
Selon un mode de réalisation, le dispositif de sécurisation n'est pas situé le long du chemin de données. Le délai de franchissement est reçu à partir dudit au moins un nœud via au moins un autre paquet de données distinct dudit au moins un paquet de données.
Selon un mode de réalisation, lorsque le dispositif de sécurisation n'est pas situé le long du chemin de données, le délai de franchissement est reçu sous une forme encryptée, le dispositif de sécurisation et ledit au moins un nœud partageant la connaissance d'au moins une information d'encryptage.
Ainsi, le transfert du délai de franchissement depuis le (ou les) nœud vers le dispositif de sécurisation est sécurisé. Par exemple, l'information d'encryptage peut utiliser certains paramètres partagés du protocole PoT.
Selon un mode de réalisation, ladite au moins une information d'encryptage est obtenue par ledit au moins un nœud via ledit au moins paquet de données.
Selon un mode de réalisation, lorsque le dispositif de sécurisation n'est pas situé le long du chemin de données, ladite au moins une action de sécurisation appartient au groupe comprenant :
inscription du délai d'errance en association avec le chemin de données dans un plan de routage d'un domaine autonome du réseau auquel appartient le chemin de données. Ainsi une sécurisation globale du réseau est obtenue via une cartographie des délais d'errance des chemins de données du réseau ; transmission du délai d'errance à au moins un autre dispositif inclus dans un nœud qui n'est pas situé le long du chemin de données pour mise en œuvre d'une autre action de sécurisation. Ainsi une action de sécurisation spécifique peut être mise en œuvre par un dispositif dédié ; et
une combinaison de tout ou partie des alternatives précitées du groupe.
Selon un mode de réalisation, l'obtention du délai d'errance correspond à une réception, via un autre paquet de données distinct dudit au moins un paquet de données, du délai d'errance depuis un autre dispositif situé le long du chemin de données. Ladite au moins une action de sécurisation appartient au groupe comprenant :
inscription du délai d'errance en association avec le chemin de données dans un plan de routage d'un domaine autonome du réseau auquel appartient le chemin de données. Ainsi une sécurisation globale du réseau est obtenue via une cartographie des délais d'errance des chemins de données du réseau ;
transmission du délai d'errance à au moins un autre dispositif inclus dans un nœud qui n'est pas situé le long du chemin de données pour mise en œuvre d'une autre action de sécurisation. Ainsi une action de sécurisation spécifique peut être mise en œuvre par un dispositif dédié ; et
une combinaison de tout ou partie des alternatives précitées du groupe.
Selon un mode de réalisation, le procédé de sécurisation est mis en œuvre successivement pour une pluralité de chemins de données du réseau.
L'invention concerne également un programme d'ordinateur comprenant des instructions de code de programme pour la mise en œuvre du procédé tel que décrit précédemment, selon l'un quelconque de ses différents modes de réalisation, lorsqu'il est exécuté sur un ordinateur.
Dans un mode de réalisation de l’invention, il est proposé un dispositif de sécurisation de la transmission d'au moins un paquet de données le long d'un chemin de données d'un réseau de télécommunications. Un tel dispositif de sécurisation comprend une machine de calcul reprogrammable ou une machine de calcul dédiée configurée pour mettre en œuvre les étapes du procédé de sécurisation selon l'invention (selon l'un quelconque des différents modes de réalisation précités).
Ainsi, les caractéristiques et avantages de ce dispositif sont les mêmes que ceux des étapes correspondantes du procédé de sécurisation décrit précédemment. Par conséquent, ils ne sont pas détaillés plus amplement.
Dans un mode de réalisation de l’invention, il est proposé un nœud d'un réseau de télécommunications. Un tel nœud de réseau comprend au moins un dispositif de sécurisation précité (selon l'un quelconque des différents modes de réalisation précités). Liste des figures
D'autres buts, caractéristiques et avantages de l'invention apparaîtront plus clairement à la lecture de la description suivante, donnée à titre de simple exemple illustratif, et non limitatif, en relation avec les figures, parmi lesquelles :
[fig. 1] représente un chemin de données d'un domaine autonome d'un réseau de télécommunications le long duquel la transmission de données est sécurisée par mise en oeuvre d'un procédé de sécurisation selon un mode de réalisation de l'invention ;
[fig. 2] représente les étapes d'un procédé de sécurisation de la transmission de données le long d'un chemin de données selon un mode de réalisation de l'invention ;
[fig. 3] représente un exemple d'échanges entre entités d'un réseau de télécommunication implémentant le procédé de sécurisation de la transmission de données selon un mode de réalisation de l'invention ;
[fig. 4] représente un exemple d'échanges entre entités d'un réseau de télécommunication implémentant le procédé de sécurisation de la transmission de données selon un autre mode de réalisation de l'invention ;
[fig. 5] représente un exemple d'échanges entre entités d'un réseau de télécommunication implémentant le procédé de sécurisation de la transmission de données selon encore un autre mode de réalisation de l'invention ;
[fig. 6] représente un exemple de structure de dispositif permettant la mise en oeuvre des étapes du procédé de la [fig. 2] selon un mode de réalisation de l'invention.
Description détaillée de modes de réalisation de l'invention
Le principe général de l'invention repose sur une obtention d'un délai d'errance d'un (ou de plusieurs) paquets de données le long d'un chemin de données (e.g. qui s'étend entre deux des noeuds du réseau). Plus particulièrement, le délai d'errance est représentatif d'un écart entre : un délai de transit de bout-en-bout effectif du paquet de données le long du chemin de données (i.e. le délai que le paquet a effectivement mis pour parcourir le chemin de données) ; et un délai de transit de bout-en-bout attendu du paquet de données le long du chemin de données (i.e. tout ou partie du délai connu, e.g. associé aux noeuds de confiance, que le paquet est supposé mettre pour parcourir le chemin de données).
Une telle métrique est pertinente afin de sécuriser la transmission de données dans le réseau et une action de sécurisation peut être mise en oeuvre sur la base d'un tel délai d'errance. Par exemple, une valeur du délai d'errance supérieure à un seuil prédéterminé est représentative du fait que le chemin de données emprunté par le paquet de données a pu être modifié, par exemple quand un dispositif tiers qui ne fait pas partie des dispositifs de confiance a été ajouté sur le chemin de données, ou si une partie des fonctions matérielles implantées le long du chemin a été déportée de manière virtualisée.
On présente désormais, en relation avec la [fig. 1] un chemin de données d'un domaine autonome AS (pour « Autonomous System » en anglais) d'un réseau de télécommunications le long duquel la transmission de données est sécurisée par un procédé de sécurisation selon un mode de réalisation de l'invention.
Plus particulièrement, un terminal utilisateur UE (pour « User Equipement » en anglais) envoie un paquet de données à destination d'un serveur Serv via le chemin de données passant par les cinq noeuds de réseau, NI à N5, qui sont ici des noeuds de confiance. Par exemple, la confiance dans les noeuds NI à N5 est établie en mettant en oeuvre le mécanisme PoT.
Un dispositif 100 de sécurisation met en oeuvre le procédé de sécurisation décrit plus avant ci-dessous en relation avec les étapes représentées sur la [fig. 2] afin de sécuriser le chemin de données entre le terminal UE et le serveur Serv.
Plus particulièrement, lors d'une étape E200, un délai d'errance représentatif d'un écart entre un délai de transit de bout-en-bout effectif d'un (ou plusieurs) paquet de données le long du chemin de données et un délai de transit de bout-en-bout attendu du (ou des) paquet de données le long du chemin de données est obtenu.
Dans le mode de réalisation de la [fig. 1], l'obtention du délai d'errance correspond à un calcul du délai d'errance par le dispositif 100.
Pour ce faire, le dispositif 100 obtient un délai de franchissement de tout ou partie des noeuds de confiance pour le (ou les) paquet de données, le délai de transit de bout-en-bout attendu au niveau du nœud dans lequel se situe le dispositif 100 étant fonction du (ou des) délai de franchissement en question.
Par exemple, le délai de franchissement est fourni par le nœud de confiance correspondant (i.e. NI ou N2 ou N3 ou N4 ou N5) au dispositif 100 afin de déterminer le délai d'errance. Pour ce faire, dans le mode de réalisation de la [fig. 1], chaque nœud de confiance ajoute son propre délai de franchissement à la valeur des délais de franchissements des nœuds précédemment traversés par le paquet ou flux le long du chemin de données. La valeur de délai de franchissement cumulatif ainsi obtenue est véhiculée dans un champ prédéfini du paquet ou du flux en question (e.g. dans le dernier paquet RESET ou GOAWAY d'une connexion QUIC, ou périodiquement dans n'importe quel paquet du flux, ou encore dans un paquet ajouté au flux comme un paquet ICMP, etc.). Il s'agit d'un mode de réalisation dit « in-band » (i.e. le délai de franchissement est inclus dans le (ou les) paquets de données sous forme d'un champ particulier). Dans d'autres modes de réalisation dit « out-of-band » la valeur du délai de franchissement est exportée vers le dispositif de sécurisation via un (ou plusieurs) paquet qui n'est pas un paquet de données transitant via le chemin de données. Par exemple, la valeur du délai de franchissement est exportée via un protocole PSAMP (pour « Packet SAMPling » en anglais) dans le cas d'un seul paquet, ou IPFIX (pour « Internet Protocol Flow Information Export » en anglais, e.g. netflow v9 pour Cisco® et Juniper) pour le cas d'un flux de paquets.
De retour à la [fig. 1], le tableau 1 ci-dessous donne des exemples de délais de franchissement (prenant en compte par exemple les délais de traitement dans les entités en question, de commutation, etc.) mis en jeu dans les différentes entités représentées sur la [fig. 1] lorsqu'elles sont connues.
[Tableau 1]
Par ailleurs, afin de calculer le délai d'errance, le dispositif 100 obtient le délai bout-en- bout effectif (i.e. entre le terminal et le serveur). Par exemple, le délai de bout-en-bout effectif est obtenu par le dispositif 100 via la demie-valeur du délai d'aller-retour du chemin de données. La valeur du délai d'aller-retour en question est obtenue par exemple via le « spinbit » lorsque le paquet de données est selon le protocole QUIC. Dans d'autres modes de réalisation, le délai bout- en-bout effectif est obtenu par mesure préalable du délai de transit le long du chemin de données.
En supposant que le délai de transit de bout-en-bout effectif dans le cas présent soit égal à 200ms, le dispositif 100 calcule le délai d'errance en soustrayant les délais de franchissement connus, ici 15 et 10 ms au délai de transit de bout-en-bout effectif. On obtient alors 200 - 15 - 10 = 175ms.
Par ailleurs, en supposant que le délai de propagation entre noeuds de confiance le long du chemin est connu, le délai d'errance peut être raffiné dans certains modes de réalisation en tenant compte du délai de propagation en question dans le calcul du délai de transit de bout-en- bout attendu. Un tel délai de propagation est obtenu par exemple par mesure préalable. Par exemple, en supposant que le délai de propagation est égal à 30 ms dans la topologie de la [fig. 1], le délai d'errance peut être raffiné en soustrayant les 30 ms en question à la valeur précédemment calculée, i.e. 175ms. On obtient au final un délai d'errance calculé comme étant égal à 175 - 30 = 145ms.
Dans d'autres modes de réalisation non représentés sur la [fig. 1], le dispositif 100 de sécurisation est implémenté non pas dans le serveur Serv, mais dans un des noeuds de confiance NI à N5. Dans ce cas, le dispositif 100 calcule le délai d'errance par rapport à sa position le long du chemin de données.
Par ailleurs, dans d'autres modes de réalisation décrits ci-dessous en relation avec les [fig. 3], [fig. 4] et [fig. 5], le dispositif de sécurisation ne calcule pas le délai d'errance, mais le reçoit d'un dispositif tiers qui a effectué le calcul. Dans ce cas, l'étape E200 d'obtention du délai d'errance se réduit à une étape de réception du délai d'errance.
Lors d'une étape E210, la transmission de données est sécurisée par mise en oeuvre d'une (ou plusieurs) action de sécurisation à partir du délai d'errance obtenu à l'étape E200.
Par exemple, dans le mode de réalisation de la [fig. 1] dans lequel le dispositif 100 de sécurisation calcule le délai d'errance sur la base d'informations (e.g. les délais de franchissement) comprises dans le (ou les) paquets de données (cas « in-band » précité), l'action de sécurisation appartient au groupe comprenant :
inscription du délai d'errance dans le (ou les) paquet de données ;
inscription du délai d'errance en association avec le chemin de données dans un plan de routage d'un domaine autonome AS du réseau auquel appartient le chemin de données (e.g. en utilisant un protocole EGP (pour « Exterior Gateway Protocol » en anglais) du type BGP (pour « Border Gateway Protocol » en anglais)) ;
destruction ou duplication pour analyse (e.g. via la transmission du paquet dupliqué à un équipement d'analyse) du (ou des) paquet de données lorsque le délai d'errance est supérieur à un seuil prédéterminé ;
transmission du délai d'errance à au moins un autre dispositif inclus dans un nœud qui n'est pas situé le long du chemin de données pour mise en œuvre d'une autre action de sécurisation (e.g. vers un collecteur implémentant un protocole IPFIX (pour « Internet Protocol Flow Information Export » en anglais)) ; et
une combinaison de tout ou partie des alternatives précitées du groupe
On présente désormais, en relation avec la [fig. 3] une mise en œuvre du procédé de sécurisation selon un mode de réalisation de l'invention.
Dans le mode de réalisation de la [fig. 3], les premier et deuxième domaines autonomes AS1 et AS2 du réseau comprennent chacun un chemin de données reliant un terminal utilisateur UE1 ou UE2 à un routeur de bordure ASBR1 ou ASBR2 (pour « Autonomous System Border Router » en anglais) via un nœud de réseau de confiance du type router R_AS1 ou R_AS2. D'autres domaines autonomes, indicés j et k sont également présents dont seuls les routeurs de bordure ASBRj et ASBRk sont représentés afin d'interfaçage avec les autres domaines autonomes du réseau.
Tout ou partie des routeurs de bordure ASBR1, ASBR2, ASBRj, ASBRk comprend un dispositif 100' de sécurisation selon un mode de réalisation différent du mode de réalisation décrit ci-dessus en relation avec la [fig. 1] Plus particulièrement, le dispositif 100' de sécurisation ne calcule pas le délai d'errance, mais le reçoit d'un dispositif tiers qui a préalablement effectué le calcul. Par exemple le dispositif 100' compris dans le routeur de bordure ASBR1 reçoit (flèche 300_1) le délai d'errance envoyé par le nœud de réseau R_AS1 qui, lui, met en œuvre le procédé selon le mode de réalisation décrit ci-dessus en relation avec la [fig. 1] (e.g. le nœud de réseau R_AS1 comprend un dispositif 100 de sécurisation comme décrit ci-dessus). Il en est de même avec le dispositif 100' compris dans le routeur de bordure ASBR2 qui reçoit (flèche 300_2) le délai d'errance envoyé par le nœud de réseau R_AS2 qui, lui, met en œuvre le procédé selon le mode de réalisation décrit ci-dessus en relation avec la [fig. 1]
De manière générale, les routeurs de bordure ASBR1, ASBR2, ASBRj, ASBRk peuvent recevoir les délais d'errance des différents chemins de données, par exemple lorsque le procédé de sécurisation est mis en œuvre successivement pour une pluralité de chemins de données du réseau. Une telle réception se fait par exemple via des informations selon un protocole IGP (pour « Interior gateway protocol » en anglais). Les routeurs de bordure ASBR1, ASBR2, ASBRj, ASBRk agrègent les délais d'errance des chemins de données pour lesquels ils reçoivent de tels délais d'errance et les insèrent comme métriques dans un protocole EGP (e.g. selon le protocole BGP) à destination des autres domaines autonomes (flèches 300_3). De telles transmissions peuvent par exemple se faire en parallèle des transmissions des informations EGP « classiques » (flèches 300_4).
De la sorte, selon le mode de réalisation de la [fig. 3] dans lequel le dispositif 100' de sécurisation reçoit le délai d'errance, l'action de sécurisation appartient au groupe comprenant : inscription du délai d'errance en association avec le chemin de données dans un plan de routage d'un domaine autonome du réseau auquel appartient le chemin de données ;
transmission du délai d'errance à au moins un autre dispositif inclus dans un nœud qui n'est pas situé le long du chemin de données pour mise en œuvre d'une autre action de sécurisation (e.g. une inscription par un dispositif tiers du délai d'errance en association avec le chemin de données dans un plan de routage) ; et
une combinaison de tout ou partie des alternatives précitées du groupe. Dans d'autres modes de réalisation non illustrés, les routeurs de bordure ASBR1, ASBR2, ASBRj, ASBRk comprennent le dispositif 100 de sécurisation selon le mode de réalisation de la [fig. 1] De la sorte, le calcul du délai d'errance du chemin de données sur lequel se trouve un routeur de bordure donné est effectué dans le routeur de bordure en question.
On présente désormais, en relation avec la [fig. 4] une mise en oeuvre du procédé de sécurisation selon un autre mode de réalisation de l'invention.
Plus particulièrement, le mode de réalisation représenté sur la [fig. 4] reprend les éléments du mode de réalisation de la [fig. 3] Seul un réflecteur de route RR1, RR_ASj, RR_ASk (pour « Route Reflector » en anglais) est utilisé dans les domaines autonomes correspondants.
De la sorte, le dispositif 100' de sécurisation est par exemple ici inclus dans le réflecteur de route RR1 de sorte à injecter les délais d'errance des chemins de données reçus du routeur de bordure ASBR1 (flèche 400_1) comme métriques dans l'EGP (e.g. selon le protocole BGP). Selon le mode de réalisation considéré discuté ci-dessus en relation avec la [fig. 3], le routeur de bordure ASBR1 a calculé lui-même le délai d'errance associé au chemin de données sur lequel il se trouve (e.g. le routeur de bordure ASBR1 comprend un dispositif 100 comme illustré sur la [fig. 4]) ou reçu le délai d'errance en question (calculé par un nœud de confiance du chemin en question qui, lui, comprend e.g. un dispositif 100 dans ce cas non illustré sur la [fig. 4]) ainsi qu'éventuellement les délais d'errance associés aux autres chemins du domaine autonome considéré.
De retour à la [fig. 4], l'EGP mis à jour est envoyé au routeur de bordure ASBR1 (flèche 400_2) afin de transmission vers les autres domaines autonomes (flèches 300_3). De telles transmissions peuvent par exemple se faire en parallèle des transmissions des informations EGP « classiques » (flèches 300_4).
Ainsi, selon le mode de réalisation de la [fig. 4] l'action de sécurisation de sécurisation est de même nature que dans le mode de réalisation décrit ci-dessus en relation avec la [fig. 3]
On présente désormais, en relation avec la [fig. 5] une mise en œuvre du procédé de sécurisation selon encore un autre mode de réalisation de l'invention.
Dans le mode de réalisation de la [fig. 5], le dispositif 100" de sécurisation calcule le délai d'errance sur la base d'informations (e.g. les délais de franchissement) qui lui sont transmises par un moyen autre que via le (ou les) paquets de données. En d'autres termes, le (ou les) paquets de données transitant le long du chemin de données pour lequel on veut obtenir le délai d'errance ne véhicule pas les délais de franchissement (mode de réalisation « out-of-band » précité). En effet, le dispositif 100" de sécurisation est ici situé dans un collecteur Coll du type IPFIX. Dans d'autres modes de réalisation, le dispositif 100" est situé dans un nœud de confiance qui n'est pas situé sur le chemin de données à sécuriser. Plus particulièrement, le dispositif 100" de sécurisation reçoit le (ou les) délai de franchissement à partir d'un nœud NI, N2, N3, N5, N6 de confiance correspondant via un (ou plusieurs) autre paquet de données distinct du (ou des) paquet de données transitant sur chemin de données pour lesquels le dispositif 100" de sécurisation va calculer le délai d'errance.
Pour ce faire, le contrôleur configure (flèches 500_1) en plus le niveau d'agrégation du flux et l'adresse du collecteur Coll dans chaque nœud NI, N2, N3, N5, N6. Le contrôleur Contr configure en plus le niveau d'agrégation du flux et les caractéristiques de la connexion avec le collecteur Coll (adresse, clés, etc.).
Ensuite les paquets de données transportent « in-band » (i.e. dans un champ de données qu'ils véhiculent eux-mêmes) les deux paramètres :
RND ; et
PoT : somme partielle du secret partagé que les nœuds NI, N2, N3, N5, N6 calculent (la constante du polynôme POLY1 selon PoT).
Comme rappelé ci-dessus, dans le mode de réalisation de la [fig. 5], le dispositif 100" de sécurisation calcule le délai d'errance sur la base d'informations (e.g. les délais de franchissement) qui ne lui sont pas transmises via le (ou les) paquets de données transitant le long du chemin de données pour lequel on veut calculer le délai d'errance (cas « out-of-band » précité). De la sorte, les nœuds NI, N2, N3, N5, N6 n'insèrent pas leur délai de franchissement dans les paquets de données transitant sur le chemin de données en question. Un nœud NI, N2, N3, N5 ou N6 ne peut donc pas calculer de délai d'errance.
Afin de protéger les échanges le contrôleur Contr active le protocole PoT sur le chemin NI vers N5 dans NI, N2 et N5. Plus particulièrement, le contrôleur Contr configure (flèches 500_1) le secret commun POLY2 et le secret de chaque nœud NI, N2, N5 du chemin (xi,yi) au niveau de chacun des nœuds en question, ainsi que du résultat attendu au niveau du dernier nœud du chemin, ici N5. N5 est donc le seul à (après le contrôleur Contr) connaître la mesure de PoT attendu (aka la constante de POLY1). Ensuite chaque nœud protège sa valeur de délai de franchissement à l'aide d'au moins un des paramètres de PoT connus ou calculable par le contrôleur Contr, par exemple POLY1, POLY2, RND et le secret de chaque nœud (xi,yi). Par exemple. Ceci permet :
La détection de la modification et authentification des nœuds de passage dans les nœuds : (xi,yi) est utilisé comme clé de signature HMAC (pour « keyed-hash message authentication code » en anglais),
La protection en lecture : RND et utilisé comme clé de chiffrement par exemple avec de l'AES (pour « Advanced Encryption Standard » en anglais). L'activation de PoT peut être partielle et limitée à POLY1. Optionnellement, pour un flux de paquets d'une connexion selon le protocole QUIC allant du terminal utilisateur UE au serveur Serv, chaque nœud NI, N2, N3, N5 ou N6 synchronise l'exportation du ticket IPFIX sur les fronts montants des « spinbit » des paquets QUIC et ajoute les mesures de demi temps de transit effectif aller-retour obtenu dans le ticket. Cela permet deux choses :
chaque nœud NI, N2, N3, N5 ou N6 exporte (flèches 500_2) vers le collecteur Coll un ticket décrivant la même séquence de paquets de données. Ceci augmente la précision de la comparaison et de l'agrégation des délais de franchissement ; et
le demi temps de transit effectif aller-retour obtenu, notamment au niveau du nœud N5, permet un calcul de délai d'errance très précis.
Un exemple de format de ticket est :
{
Flux identifier quintuplé, ...
to,
tl,
nombre d'octets,
nombre paquets,
délai de franchissement local cumulé,
Spatial delay : {demi temps de transit effectif aller-retour montant, demi temps de transit effectif aller-retour descendant}
}
Le dispositif 100" du collecteur Coll reçoit les délais de franchissement des différents nœuds NI, N2, N3, N5, N6. Il les déchiffre à l'aide des « decryption keys » reçues du contrôleur Contr lors de la configuration comme décrit ci-dessus (En d'autres termes, le dispositif 100" déchiffre (ou décrypte) les délais de franchissement des différents nœuds NI, N2, N3, N5, N6 sur la base d'informations d'encryptage qui ont été obtenues par les différents nœuds en question NI, N2, N3, N5, N6 via le (ou les) paquets de données transitant le long du chemin de données considéré. De telles informations d'encryptage sont utilisées par les différents nœuds en question pour chiffrer (ou encrypter) leur délai de franchissement respectif). Le dispositif 100" regroupe les délais de franchissement reçus des différents nœuds NI, N2, N3, N5, N6 par flux de paquets de données suivant les flow agrégation également reçues du contrôleur Contr lors de la configuration. Le dispositif 100" calcule un délai d'errance pour le chemin de données correspondant à l'agrégation demandée.
Le dispositif 100" regroupe les résultats dans une matrice de délais d'errance. Les entrées de la matrice correspondent au niveau d'agrégation du flux choisi (host, network, système autonome). Le dispositif 100" permet l'accès à la matrice à l'aide par exemple du protocole ALTO (pour « Application-Layer Traffic Optimization » en anglais). Le dispositif 100" de sécurisation mesure la variation de délai d'errance. Il signale une augmentation excessive comme une attaque possible d'un nœud du chemin sur le flux de paquets.
Alternativement, ou en combinaison, le dispositif 100" de sécurisation transmet le (ou les) délai d'errance à au moins un autre dispositif inclus dans un nœud qui n'est pas situé le long du chemin de données pour mise en œuvre d'une autre action de sécurisation (e.g. une inscription par un dispositif tiers du (ou des) délai d'errance en association avec le chemin de données dans un plan de routage).
Ainsi, selon le mode de réalisation de la [fig. 5] l'action de sécurisation est de même nature que dans le mode de réalisation décrit ci-dessus en relation avec les [fig. 3] et [fig. 4]
Par exemple, le dispositif 100" de sécurisation transmet le (ou les) délai d'errance à un réflecteur de route RR (e.g. le réflecteur de route RR comprend un dispositif 100' comme illustré sur la [fig. 5]) de sorte à injecter le (ou les) délai d'errance des chemins de données calculés ou reçus (flèche 500_3) comme métriques dans l'EGP (e.g. selon le protocole BGP). L'EGP mis à jour est renvoyé par le réflecteur de route RR à tout ou partie des nœuds NI, N2, N3, N5, N6 (flèche 500_4).
Dans d'autres modes de réalisation, d'autres types de protection que celle mise en œuvre dans le protocole PoT sont utilisées pour la transmission des données (e.g. le (ou les) délai de franchissement ou de lien) au dispositif de sécurisation.
Dans encore d'autres modes de réalisation, aucune protection des données n'est mise en œuvre pour la transmission des données (e.g. le (ou les) délai de franchissement ou de lien) au dispositif de sécurisation.
On présente désormais, en relation avec la [fig. 6] un exemple de structure de dispositif 600 permettant de mettre en œuvre les étapes du procédé de sécurisation de la [fig. 2] selon un mode de réalisation de l'invention.
Le dispositif 600 comprend une mémoire vive 603 (par exemple une mémoire RAM), une unité de traitement 602 équipée par exemple d’un processeur, et pilotée par un programme d’ordinateur stocké dans une mémoire morte 601 (par exemple une mémoire ROM ou un disque dur). A l’initialisation, les instructions de code du programme d’ordinateur sont par exemple chargées dans la mémoire vive 603 avant d’être exécutées par le processeur de l’unité de traitement 602.
Cette [fig. 6] illustre seulement une manière particulière, parmi plusieurs possibles, de réaliser le dispositif 600 afin qu'il effectue certaines étapes du procédé de sécurisation selon l'invention (selon l'un quelconque des modes de réalisation et/ou variantes décrit(e)s ci-dessus en relation avec la [fig. 2]). En effet, ces étapes peuvent être réalisées 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ù le dispositif 600 est réalisé avec 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 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.
Dans certains modes de réalisation, le dispositif 600 implémente l'un quelconque des dispositifs de sécurisation 100, 100' ou 100".
Dans certains modes de réalisation, le dispositif 600 implémente plusieurs ou la totalité des dispositifs de sécurisation 100, 100' ou 100".
Dans certains modes de réalisation, le dispositif 600 est inclus dans un nœud de réseau
(e.g. NI, N2, N3, N4, N5, N6, RR, Coll, AS B R, R_AS, etc.).

Claims

REVENDICATIONS
1. Procédé de sécurisation de la transmission d'au moins un paquet de données le long d'un chemin de données d'un réseau de télécommunications,
caractérisé en ce qu'un dispositif (100, 100', 100", 600) de sécurisation effectue les étapes suivantes :
obtention (E200) d'un délai d'errance représentatif d'un écart entre un délai de transit de bout-en-bout effectif dudit au moins un paquet de données le long dudit chemin de données et un délai de transit de bout-en-bout attendu dudit au moins un paquet de données le long dudit chemin de données ; et
sécurisation (E210) de ladite transmission par mise en oeuvre d'au moins une action de sécurisation à partir dudit délai d'errance.
2. Procédé selon la revendication 1 dans lequel ladite obtention dudit délai d'errance correspond à un calcul dudit délai d'errance comprenant une obtention dudit délai de transit de bout-en-bout effectif par :
mesure préalable dudit délai de transit de bout-en-bout le long dudit chemin de données ; ou par
mesure préalable d'une demie valeur du délai de transit aller-retour le long dudit chemin de données.
3. Procédé selon la revendication 2 dans lequel ledit chemin de données passe par au moins un nœud dudit réseau,
et dans lequel, pour chacun desdits nœuds, ledit calcul dudit délai d'errance comprend une obtention d'un délai de franchissement dudit nœud pour ledit au moins un paquet de données,
ledit délai de transit de bout-en-bout attendu étant fonction dudit au moins un délai de franchissement.
4. Procédé selon la revendication 3 dans lequel ledit chemin de données passe par au moins deux nœuds dudit réseau,
et dans lequel, pour chaque paire de nœuds parmi lesdits au moins deux nœuds, ledit calcul dudit délai d'errance comprend une obtention d'un délai de propagation dudit au moins un paquet de données le long dudit chemin de données entre les nœuds de ladite paire de nœuds, ledit délai de transit de bout-en-bout attendu étant fonction dudit au moins un délai de propagation.
5. Procédé selon la revendication 4 dans lequel ledit délai d'errance est calculé comme une fonction dudit délai de transit de bout-en-bout effectif auquel est soustrait ledit au moins un délai de franchissement et/ou ledit au moins un délai de propagation.
6. Procédé selon l'une quelconque des revendications 3 à 5 dans lequel ledit chemin de données s'étend entre un premier et un deuxième nœud de réseau dudit réseau, ledit dispositif (100, 600) de sécurisation étant logé dans ledit deuxième nœud de réseau,
dans lequel ledit au moins un délai de franchissement est obtenu à partir d'au moins un paramètre véhiculé au sein dudit au moins un paquet de données.
7. Procédé selon l'une quelconque des revendications 1 à 6 dans lequel ladite au moins une action de sécurisation appartient au groupe comprenant :
inscription dudit délai d'errance dans ledit au moins un paquet de données ;
inscription dudit délai d'errance en association avec ledit chemin de données dans un plan de routage d'un domaine autonome dudit réseau auquel appartient ledit chemin de données ;
destruction ou duplication pour analyse dudit au moins un paquet de données lorsque ledit délai d'errance est supérieur à un seuil prédéterminé ;
transmission dudit délai d'errance à au moins un autre dispositif inclus dans un nœud qui n'est pas situé le long dudit chemin de données pour mise en œuvre d'une autre action de sécurisation ; et
une combinaison de tout ou partie des alternatives précitées du groupe.
8. Procédé selon l'une quelconque des revendications 3 à 5 dans lequel ledit dispositif (100", 600) de sécurisation n'est pas situé le long dudit chemin de données,
et dans lequel ledit délai de franchissement est reçu à partir dudit au moins un nœud via au moins un autre paquet de données distinct dudit au moins un paquet de données.
9. Procédé selon la revendication 8 dans lequel ledit délai de franchissement est reçu sous une forme encryptée, ledit dispositif de sécurisation et ledit au moins un nœud partageant la connaissance d'au moins une information d'encryptage.
10. Procédé selon l'une quelconque des revendications 1 à 5, ou selon la revendication 8 ou 9, dans lequel ladite au moins une action de sécurisation appartient au groupe comprenant : inscription dudit délai d'errance en association avec ledit chemin de données dans un plan de routage d'un domaine autonome dudit réseau auquel appartient ledit chemin de données ; transmission dudit délai d'errance à au moins un autre dispositif inclus dans un nœud qui n'est pas situé le long dudit chemin de données pour mise en œuvre d'une autre action de sécurisation ; et
une combinaison de tout ou partie des alternatives précitées du groupe.
11. Procédé selon la revendication 1 dans lequel ladite obtention dudit délai d'errance correspond à une réception, via un autre paquet de données distinct dudit au moins un paquet de données, dudit délai d'errance depuis un autre dispositif situé le long dudit chemin de données,
et dans lequel ladite au moins une action de sécurisation appartient au groupe comprenant : inscription dudit délai d'errance en association avec ledit chemin de données dans un plan de routage d'un domaine autonome dudit réseau auquel appartient ledit chemin de données ; transmission dudit délai d'errance à au moins un autre dispositif inclus dans un nœud qui n'est pas situé le long dudit chemin de données pour mise en œuvre d'une autre action de sécurisation ; et
une combinaison de tout ou partie des alternatives précitées du groupe.
12. Produit programme d'ordinateur comprenant des instructions de code de programme pour la mise en œuvre du procédé selon l'une quelconque des revendications 1 à 11, lorsque ledit programme est exécuté sur un ordinateur.
13. Dispositif (100, 100', 100", 600) de sécurisation de la transmission d'au moins un paquet de données le long d'un chemin de données d'un réseau de télécommunications,
caractérisé en ce qu'il comprend une machine de calcul reprogrammable (602) ou une machine de calcul dédiée, configurée pour :
obtenir un délai d'errance représentatif d'un écart entre un délai de transit de bout-en- bout effectif dudit au moins un paquet de données le long dudit chemin de données et un délai de transit de bout-en-bout attendu dudit au moins un paquet de données le long dudit chemin de données ; et
sécuriser ladite transmission par mise en œuvre d'au moins une action de sécurisation à partir dudit délai d'errance.
14. Nœud (NI, N2, N3, N4, N5, N6, RR, Coll, ASBR, R_AS) d'un réseau de télécommunications caractérisé en ce qu'il comprend au moins un dispositif selon la revendication 13.
EP20726188.4A 2019-03-22 2020-03-13 Procédé de sécurisation de la transmission d'au moins un paquet de données le long d'un chemin de données d'un réseau de télécommunications, produit programme d'ordinateur et dispositif correspondants Pending EP3942772A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR1902974A FR3094163A1 (fr) 2019-03-22 2019-03-22 Procédé de sécurisation de la transmission d’au moins un paquet de données le long d’un chemin de données d’un réseau de télécommunications, produit programme d’ordinateur et dispositif correspondants.
PCT/FR2020/050530 WO2020193902A1 (fr) 2019-03-22 2020-03-13 Procédé de sécurisation de la transmission d'au moins un paquet de données le long d'un chemin de données d'un réseau de télécommunications, produit programme d'ordinateur et dispositif correspondants

Publications (1)

Publication Number Publication Date
EP3942772A1 true EP3942772A1 (fr) 2022-01-26

Family

ID=67742595

Family Applications (1)

Application Number Title Priority Date Filing Date
EP20726188.4A Pending EP3942772A1 (fr) 2019-03-22 2020-03-13 Procédé de sécurisation de la transmission d'au moins un paquet de données le long d'un chemin de données d'un réseau de télécommunications, produit programme d'ordinateur et dispositif correspondants

Country Status (4)

Country Link
US (1) US12355808B2 (fr)
EP (1) EP3942772A1 (fr)
FR (1) FR3094163A1 (fr)
WO (1) WO2020193902A1 (fr)

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2018068900A1 (fr) * 2016-10-11 2018-04-19 Conti Temic Microelectronic Gmbh Procédé de surveillance d'un réseau pour des anomalies

Family Cites Families (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20030033404A1 (en) * 2001-08-09 2003-02-13 Richardson David E. Method for automatically monitoring a network
US20030112758A1 (en) * 2001-12-03 2003-06-19 Pang Jon Laurent Methods and systems for managing variable delays in packet transmission
TW200414737A (en) * 2002-09-27 2004-08-01 Matsushita Electric Industrial Co Ltd Contents transmission system
US8750267B2 (en) * 2009-01-05 2014-06-10 Qualcomm Incorporated Detection of falsified wireless access points
JP5849786B2 (ja) * 2012-03-08 2016-02-03 富士通株式会社 データブロック出力装置、通信システム、データブロック出力方法、及び通信方法
US20150009840A1 (en) * 2013-07-03 2015-01-08 Niksun, Inc. Packet time stamp processing methods, systems, and apparatus
KR102029849B1 (ko) * 2015-01-27 2019-10-08 노키아 솔루션스 앤드 네트웍스 오와이 트래픽 흐름 모니터링

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2018068900A1 (fr) * 2016-10-11 2018-04-19 Conti Temic Microelectronic Gmbh Procédé de surveillance d'un réseau pour des anomalies

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
See also references of WO2020193902A1 *
ZHANG TING ET AL: "Exposing End-to-End Delay in Software-Defined Networking", INTERNATIONAL JOURNAL OF RECONFIGURABLE COMPUTING, vol. 2019, 4 March 2019 (2019-03-04), Cairo / New York, pages 1 - 12, XP093357044, ISSN: 1687-7195, Retrieved from the Internet <URL:http://downloads.hindawi.com/journals/ijrc/2019/7363901.xml> DOI: 10.1155/2019/7363901 *

Also Published As

Publication number Publication date
FR3094163A1 (fr) 2020-09-25
US20220159037A1 (en) 2022-05-19
US12355808B2 (en) 2025-07-08
WO2020193902A1 (fr) 2020-10-01

Similar Documents

Publication Publication Date Title
Dhamdhere et al. Inferring persistent interdomain congestion
US9392009B2 (en) Operating a network monitoring entity
FR3009163A1 (fr) Procede pour l&#39;echange en securite d&#39;une donnee sur un reseau ad-hoc mettant en oeuvre un service de diffusion xcast; noeud associe
EP3991391A1 (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é
Chen et al. One primitive to diagnose them all: Architectural support for internet diagnostics
EP1743452A1 (fr) Mesure de performance dans un reseau de transmission de paquets
FR3118383A1 (fr) Procédé d’apprentissage collaboratif entre une pluralité de nœuds d’un réseau d’un modèle de détection d’anomalies
EP2211504A1 (fr) Procédé de classification coopérative de trafics IP
Choffnes et al. An empirical evaluation of deployed dpi middleboxes and their implications for policymakers
FR3017762A1 (fr) Notification d&#39;une information de consommation de bande passante a un fournisseur de service dans un reseau de telecommunications
WO2007099245A2 (fr) Procede de collecte de descriptions de flux portant sur des flux relatifs a au moins un reseau client rattache a un reseau d&#39;interconnexion
CN101854366A (zh) 一种对等网络流量识别的方法及装置
WO2020193902A1 (fr) Procédé de sécurisation de la transmission d&#39;au moins un paquet de données le long d&#39;un chemin de données d&#39;un réseau de télécommunications, produit programme d&#39;ordinateur et dispositif correspondants
EP3682600A1 (fr) Gestion de la connexion avec d&#39;autres passerelles residentielles d&#39;une passerelle residentielle mettant en oeuvre l&#39;agregation de liens
WO2025201931A1 (fr) Procédé et dispositif de détection et d&#39;identification d&#39;algorithmes cryptographiques dans un réseau de communication
WO2020221779A1 (fr) Procedes et dispositifs de mesure de reputation dans un reseau de communication
Brockners Next-gen Network Telemetry is Within Your Packets: In-band OAM
EP3785403B1 (fr) Procédé d&#39;élaboration de données d&#39;utilisation de relais utilisés au cours d&#39;une communication entre deux appareils, de recherche desdites données, et appareils associés
EP2456135A1 (fr) Procédé et dispositif de détermination de chemin(s) de communication entre des équipements de communication à interfaces de communication multiples
EP4128701A1 (fr) Procédé de gestion de communications et dispositifs associés
WO2015197978A1 (fr) Procede de protection d&#39;un routeur contre des attaques
Torres et al. Characterization of community based-P2P systems and implications for traffic localization
EP1986398A1 (fr) Procédé de filtrage de flots indésirables en provenance d&#39;un terminal présumé malveillant
Souihi et al. Troubleshooting for Network Operators: The Road to a New Paradigm with Encrypted Traffic
WO2014135794A1 (fr) Procede de controle de congestion pour reseaux de telecommunications

Legal Events

Date Code Title Description
STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: UNKNOWN

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE INTERNATIONAL PUBLICATION HAS BEEN MADE

PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: REQUEST FOR EXAMINATION WAS MADE

17P Request for examination filed

Effective date: 20210802

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MK MT NL NO PL PT RO RS SE SI SK SM TR

DAV Request for validation of the european patent (deleted)
DAX Request for extension of the european patent (deleted)
STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: EXAMINATION IS IN PROGRESS

17Q First examination report despatched

Effective date: 20240624