WO2020008159A1 - Identification de protocole d'un flux de données - Google Patents

Identification de protocole d'un flux de données Download PDF

Info

Publication number
WO2020008159A1
WO2020008159A1 PCT/FR2019/051682 FR2019051682W WO2020008159A1 WO 2020008159 A1 WO2020008159 A1 WO 2020008159A1 FR 2019051682 W FR2019051682 W FR 2019051682W WO 2020008159 A1 WO2020008159 A1 WO 2020008159A1
Authority
WO
WIPO (PCT)
Prior art keywords
protocol
data
data flow
identify
signatures
Prior art date
Application number
PCT/FR2019/051682
Other languages
English (en)
Inventor
Jérôme TOLLET
Original Assignee
Qosmos Tech
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 Qosmos Tech filed Critical Qosmos Tech
Priority to JP2020572750A priority Critical patent/JP7412363B2/ja
Priority to KR1020207036935A priority patent/KR20210043498A/ko
Priority to CA3103363A priority patent/CA3103363A1/fr
Priority to EP19748867.9A priority patent/EP3818676A1/fr
Publication of WO2020008159A1 publication Critical patent/WO2020008159A1/fr
Priority to US17/124,724 priority patent/US11265372B2/en

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • H04L67/104—Peer-to-peer [P2P] networks
    • H04L67/1087—Peer-to-peer [P2P] networks using cross-functional networking aspects
    • H04L67/1091—Interfacing with client-server systems or between P2P systems
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00—Arrangements for monitoring or testing data switching networks
    • H04L43/18—Protocol analysers
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/06—Management of faults, events, alarms or notifications
    • H04L41/0604—Management of faults, events, alarms or notifications using filtering, e.g. reduction of information by using priority, element types, position or time
    • H04L41/0627—Management of faults, events, alarms or notifications using filtering, e.g. reduction of information by using priority, element types, position or time by acting on the notification or alarm source
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/1066—Session management
    • H04L65/1101—Session protocols
    • H04L65/1104—Session initiation protocol [SIP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/02—Protocols based on web technology, e.g. hypertext transfer protocol [HTTP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/60—Scheduling or organising the servicing of application requests, e.g. requests for application data transmissions using the analysis and optimisation of the required network resources
    • H04L67/61—Scheduling or organising the servicing of application requests, e.g. requests for application data transmissions using the analysis and optimisation of the required network resources taking into account QoS or priority requirements

Definitions

  • the present invention relates to data processing in telecommunications networks, and in particular the recognition of data flow protocols.
  • data flow means any set of data exchanged between two network entities, for example between a client and a server, or between two clients (so-called peer-to-peer flows, or P2P).
  • flow analyzers can be arranged intercepted in network access points, such as Wi-Fi stations, firewalls or proxy servers for example.
  • the configuration of a security system can be based on the recognition of the properties of certain protocols in order to prevent certain types of transfer.
  • a data flow analyzer thus provides the firewall with a classification of the data flow based on recognized protocols.
  • a traffic analysis system between two entities includes a first network 100 comprising a first entity 11 2 (of the client type for example) connected to a second network 1 10 comprising a second entity 1 1 1 (of the server type for example) by a communication link 120.
  • the link 120 is analyzed by an analyzer 300, which measures and analyzes traffic in both directions or in a single direction between the first network 100 and second network 1 10.
  • the traffic between networks 100 and 1 10 can be of the order of Gigabit per second, Gbps, in corporate networks, but can reach ten Gbps in the core of 'a network of an operator.
  • the amount of data passing through a telecommunications network also makes analysis and classification costly in terms of resources.
  • the measurement and analysis capacity of the analyzer 300 is determined by the number N of simultaneous flows and the flow rate T of each flow.
  • N directly affects the amount of memory required to manage the context of the recorded streams
  • T directly impacts the computing power required to implement the analysis and classification without significant loss of packets and without delaying the stream.
  • T defines the quantity of packets to be processed in a given period of time and, thus, the quantity of processing resources which can be allocated to each packet.
  • N and T both increase proportionally in existing computer networks.
  • patent EP1722509 proposes a hierarchical analysis based on recognition of a protocol which is explicit firstly, and implicitly secondly, if explicit recognition is not possible. .
  • Explicit recognition is notably implemented when a layer of given level explicitly indicates the protocol used for the layer of higher level that it encapsulates.
  • the Ethernet layer explicitly indicates whether the upper layer is IPv4 or IPv6, and IP indicates whether the upper layer is TCP or UDP.
  • IP indicates whether the upper layer is TCP or UDP.
  • identifying protocols such as SMTP and HTTP is easier and less resource intensive than identifying a protocol such as Bittorrent, whose data is encrypted.
  • the classification of data flows should therefore be optimized by reducing complexity without reducing reliability.
  • the present invention improves the situation.
  • a grammatical analysis consumes little computing resources and makes it possible to identify most of the protocols which cannot be identified explicitly.
  • the signature-based analysis method which consumes more computing resources, is only implemented in the event of grammatical analysis failure, which optimizes the use of resources during implicit identification of a protocol.
  • the invention can further comprise, in the event of failure to identify the protocol of the data stream by consulting the signature engine, the application of a statistical method of protocol recognition in order to '' identify the data flow protocol.
  • Such a method also consumes computing resources, and is not completely reliable. It is therefore advantageously implemented if the first two methods fail. It also allows to recognize encrypted protocols such as Bittorrent, which cannot be recognized by the two previous methods.
  • the identified protocol can be an application level protocol.
  • the application level protocols and more generally the protocols of layers 5 to 7 of the OSI model, are not explicitly indicated by the lower level layers, and the method is therefore advantageously applied to them according to this embodiment.
  • the method may further comprise a step of identifying protocol data by the application of a simple algorithm switches to contextual elements of the data flow according to the identified protocol.
  • Such an algorithm consumes few resources, and thus makes it possible, for a given identified protocol, to differentiate the data that they transport between different types of protocol data.
  • the method may further comprise consulting a signature engine matching protocol data with corresponding signatures, and the sequential application of the signatures to the data stream to identify the protocol data of the data stream.
  • the signature-based analysis method which consumes more computing resources, is only implemented in the event of grammatical analysis failure, which makes it possible to optimize the use of resources during implicit identification of protocol data.
  • the method can further comprise a step of processing the data stream on the basis of the identified protocol of the data stream.
  • differential treatment by protocol can be applied.
  • processing the data flow can include at least one of the following steps:
  • a second aspect of the invention relates to a computer program product comprising instructions for implementing the method according to the first aspect of the invention, when this program is executed by a processor.
  • a third aspect of the invention relates to a device for identifying a protocol of a data stream exchanged between two entities of a telecommunications network, the device comprising:
  • - a processor configured for:
  • FIG. 1 illustrates a general architecture of a system according to an embodiment of the invention
  • FIG. 2 is a diagram showing the steps of a treatment method according to an embodiment of the invention.
  • FIG. 3 illustrates the structure of a data processing device according to an embodiment of the invention.
  • the invention can be implemented in a protocol identification device such as the analyzer 300 illustrated in FIG. 1.
  • the identification device will be presented in more detail with reference to FIG. 3.
  • FIG. 2 presents the steps of a protocol identification method according to an embodiment of the invention.
  • a step 200 one or more packets of a flow are received by the identification device, for example following an interception of the packets by the analyzer 300 on the communication link 200.
  • a received data packet can be identified to be associated with an existing stream or to create a new entry in a table listing the current data streams. For example, an IP address (and possibly a port number) of a source entity and an IP address (and possibly a port number) of a recipient entity can be taken into account to identify the flow corresponding to the packet.
  • IP address and possibly a port number
  • IP address and possibly a port number
  • the source or recipient entity can designate either a client or a server.
  • the client can be a laptop or desktop computer, a touch pad, a Smartphone or any electronic device comprising an interface making it possible to communicate in the network 100 or 110, such as the Internet for example.
  • the two communicating entities can be in two separate networks as illustrated in FIG. 1 or can belong to the same network.
  • the lower layer protocols of the data stream can be determined in step 201 by explicit recognition.
  • explicit recognition requires little computing power in that the protocol of a layer of a given level can be explicitly indicated by the layer of the level which is directly below it.
  • the IPv4 or IPv6 protocol is used from data of the Ethernet layer.
  • the IP layer indicates whether the UDP or TCP protocol is used.
  • the method according to the invention aims to identify a protocol which is not explicitly signaled by the layers of lower levels. Such identification is therefore implicit. For example, the recognition of a layer protocol from level 5 to 7 of the OSI level, and in particular of level 7 (application), is considered.
  • the identification device implements a grammatical analysis of the data of the data stream, contained in the packet or packets of the data stream, with a view to identifying a protocol of the data flow.
  • some application-level protocols have a grammar that is easily identifiable by implementing low computing power. This is for example the case of the SMTP and HTTP protocols.
  • Such protocols have contextual elements useful for their recognition. For example, they both use a handshake process for establishing the flow.
  • Other protocols such as SSL or SIP can also be identified by recognition of their grammar. It should be noted that statistically, 90% of the protocols for applying the flows to be classified can be recognized by using step 203. Using such a recognition method first makes it possible to recognize a large number of protocols with a low computing power.
  • step 203 it is checked whether the data flow protocol has been successfully identified by grammar analysis.
  • the method may further comprise a step 204 of identifying protocol data by applying a single pass algorithm (“one pass” or “single pass” in English) to contextual elements of the data flow according to the identified protocol.
  • the single pass algorithm may depend on the protocol identified.
  • the identification of the protocol data can be considered as the identification of an application or sub-application of a layer higher than the layer of the protocol identified in step 203.
  • the protocol identified as being HTTP the upper layer sub-application, or protocol data, can be Facebook TM data for example.
  • the application of the single pass algorithm can consist of the injection of contextual elements of the flow (for example, for HTTP, the contextual elements can be elements such as the URL, User Agent, etc.) in a rules.
  • a flow context element is any header or payload element in the data flow.
  • the engine rules can return a set of rules that can be tested on the protocol data identified in step 102 to identify the protocol data. For example, after identifying the HTTP protocol in step 202, the protocol data can be identified as Facebook TM data.
  • a step 212 it is checked whether the protocol data have been identified in the step 204 by means of the single pass algorithm. If successful, the process continues with step 205. If it fails, the process proceeds to step 206 described below.
  • Steps 204 and 205 are optional and the method can pass directly from step 203 to 205 in the event of positive identification in step 203.
  • the method can comprise the application of a step 205 of processing the data stream as a function of the identified protocol, and possibly as a function of the application data.
  • the processing of the flow can for example consist in applying a quality of service policy depending on the identified protocol or in authorizing or prohibiting the flow of data on the basis of the identified protocol, or can more generally consist in classifying the flow according to the identified protocol .
  • the classification can be transmitted to a processing device external to the protocol identification device.
  • the method according to the invention comprises a step 206 of consulting a signature engine matching protocols with corresponding signatures.
  • the signatures are applied sequentially to the data flow in order to identify the application level protocol of the data flow. Such a sequential application is more costly in terms of resources, and is therefore advantageously applied only if the grammatical analysis in step 202 fails.
  • such a signature search method provides access to half of the 10% of application protocols that could not be identified by the grammatical analysis method (i.e. 5% of the protocols). Although more expensive in computing resources, the search method of signatures nevertheless remains reliable.
  • the steps 206 and 207 can also be applied to the protocol data in the event of failure to identify in step 204.
  • the protocol data are compared with signatures for their identification.
  • a step 208 it is checked whether the data flow protocol has been successfully identified by the signature search method.
  • an embodiment of the invention may provide an additional step 209 of applying a statistical protocol recognition method in order to identify the application protocol of the data flow (or the protocol data) .
  • a statistical protocol recognition method notably makes it possible to identify encrypted protocols, such as Bittorrent.
  • Such a method is costly in computing power (sequential search) and is not completely reliable. However, it makes it possible to identify 1 to 2% of the protocols or protocol data which have not been identified by the methods implemented previously.
  • a step 210 it is checked whether the data flow protocol has been successfully identified by the statistical method.
  • a predefined processing can be applied in a step 211 in the event of failure. For example, as a precaution, the data flow may be blocked.
  • FIG. 3 represents a protocol identification device 301 according to an embodiment of the invention.
  • the identification device 301 can be implemented in the analyzer 300 located in interception between the networks 100 and 110 of FIG. 1. More generally, it is capable of receiving data from data streams passing between two network entities.
  • the identification device comprises a random access memory 305 and a processor 304, as well as a memory 301 for storing instructions allowing the implementation of the steps of the method described above with reference to FIG. 2.
  • the processor can include sub-entities 304.1 to 304.3 respectively dedicated to the three recognition methods described above.
  • the memory 301 can also store data used by the processor for the implementation of the method, in particular:
  • the identification device 301 further comprises an input interface 302 intended to receive the data of data flow circulating on the communication link 200 or in a given network.
  • the identification device 301 further comprises an output interface 303 capable of providing a protocol identification result, or a command determined from the identified protocol.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Business, Economics & Management (AREA)
  • General Business, Economics & Management (AREA)
  • Multimedia (AREA)
  • Computing Systems (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Computer And Data Communications (AREA)
  • Communication Control (AREA)
  • Maintenance And Management Of Digital Transmission (AREA)

Abstract

Identification de protocole d'un flux de données L'invention concerne un procédé d'identification d'un protocole d'un flux de données échangé entre deux entités d'un réseau de télécommunication, le procédé de traitement comprenant les étapes suivantes: -sur réception (200) de données du flux de données, analyse grammaticale (202) dudit flux de données en vue d'identifier un protocole du flux de données; -en cas d'échec (203) de l'identification du protocole du flux de données par l'analyse grammaticale, consultation (206) d'un moteur de signatures mettant en correspondance des protocoles avec des signatures correspondantes, et application séquentielle (207) des signatures au flux de données en vue d'identifier un protocole du flux de données.

Description

Identification de protocole d’un flux de données
La présente invention concerne le traitement de données dans des réseaux de télécommunications, et notamment la reconnaissance de protocoles de flux de données.
Elle concerne plus précisément des applications de surveillance et de catégorisation de flux de données transitant sur des réseaux de télécommunications, par exemple des flux internet.
Dans la suite, on entend par flux de données tout ensemble de données échangées entre deux entités réseaux, par exemple entre un client et un serveur, ou entre deux clients (flux dits pair à pair, ou P2P).
Il est connu d’appliquer différentes méthodes de classification de flux de données afin de détecter un format de données, ou un protocole employé pour leur transport, en vue de filtrer les flux de données, de catégoriser un flux afin de permettre de traiter le flux de données en fonction de sa classification.
A cet effet, des analyseurs de flux peuvent être disposés en interception dans des points d’accès réseau, tels que des bornes Wi-fi, des pare-feu ou de serveurs de proxy par exemple.
Dans un pare-feu, la configuration d’un système de sécurité peut être basée sur la reconnaissance de propriétés de certains protocoles afin d’empêcher certains types de transfert. Un analyseur de flux de données permet ainsi de fournir au pare-feu une classification du flux de données basée sur les protocoles reconnus.
Par exemple, en référence à la figure 1 , un système d’analyse de trafic entre deux entités (client et/ou serveur) inclut un premier réseau 100 comprenant une première entité 1 12 (de type client par exemple) connecté à un second réseau 1 10 comprenant une deuxième entité 1 1 1 (de type serveur par exemple) par un lien de communication 120. Le lien 120 est analysé par un analyseur 300, qui mesure et analyse le trafic dans les deux directions ou dans une seule direction entre le premier réseau 100 et le deuxième réseau 1 10. Le trafic entre les réseaux 100 et 1 10 peut être de l’ordre du Gigabit par seconde, Gbps, dans des réseaux d’entreprise, mais peut atteindre la dizaine de Gbps dans le cœur d’un réseau d’un opérateur. La quantité de données transitant sur un réseau de télécommunications rend par ailleurs l’analyse et la classification coûteuses en termes de ressources.
La capacité de mesure et d’analyse de l’analyseur 300 est déterminée par le nombre N de flux simultanés et le débit T de chaque flux. N affecte directement la quantité de mémoire requise pour gérer le contexte des flux enregistrés, tandis que T impacte directement la puissance de calcul requise pour mettre en œuvre l’analyse et la classification sans perte significative de paquets et sans retarder le flux. T définit la quantité de paquets à traiter dans un laps de temps donné et, ainsi, la quantité de ressources de traitement qui peut être allouée à chaque paquet.
Dans des systèmes connus, la quantité de ressources de traitement augmente proportionnellement avec l’augmentation des flux N. A ressources fixes, une infrastructure de données peut uniquement augmenter N en diminuant T, ou augmenter T en diminuant N. Exprimé autrement, la produit N*T reste sensiblement constant.
Toutefois, en pratique, N et T augmentent tous les deux de manière proportionnelle dans les réseaux informatiques existants.
Afin de tenter de palier à de tels inconvénients, le brevet EP1722509, du même déposant, propose une analyse hiérarchisée reposant sur une reconnaissance de protocole explicite dans un premier temps, et implicite dans un second temps, si la reconnaissance explicite n’est pas possible.
Une reconnaissance explicite est notamment mise en œuvre lorsqu’une couche de niveau donné indique explicitement le protocole utilisé pour la couche de niveau supérieur qu’elle encapsule. Par exemple, la couche Ethernet indique explicitement si la couche supérieure est IPv4 ou IPv6, et IP indique si la couche supérieure est TCP ou UDP. Une telle reconnaissance est aisée et requiert peu de puissance de calcul.
En ce qui concerne les couches de niveau applicatif, elles sont le plus souvent identifiées par une méthode de reconnaissance de type implicite, plus coûteuse en ressources, car elles ne sont pas explicitement indiquées par la couche de transport de niveau inférieur. En outre, la diversité des encodages de protocoles de ce niveau ainsi que l’émergence du chiffrement des communications requièrent de nouvelles méthodes de reconnaissance de protocole.
Par exemple, l’identification de protocoles tels que SMTP et HTTP est plus aisée et moins consommatrice en ressource que l’identification d’un protocole tel que Bittorrent, dont les données sont chiffrées. Il conviendrait ainsi d’optimiser la classification de flux de données en réduisant la complexité sans réduire la fiabilité.
La présente invention vient améliorer la situation.
Elle propose à cet effet un procédé d’identification d’un protocole d’un flux de données échangé entre deux entités d’un réseau de télécommunication, le procédé de traitement comprenant les étapes suivantes :
- sur réception de données du flux de données, analyse grammaticale du flux de données en vue d’identifier un protocole du flux de données ;
- en cas d’échec de l’identification du protocole du flux de données par l’analyse grammaticale, consultation d’un moteur de signatures mettant en correspondance des protocoles avec des signatures correspondantes, et application séquentielle des signatures au flux de données en vue d’identifier un protocole du flux de données.
Une analyse grammaticale est peu consommatrice en ressources de calculs et permet d’identifier la plupart des protocoles qui ne peuvent être identifiés de manière explicite. La méthode d’analyse basée sur les signatures, plus consommatrices en ressources de calcul, est uniquement mise en œuvre en cas d’échec de l’analyse grammaticale, ce qui permet d’optimiser l’utilisation de ressources lors de l’identification implicite d’un protocole.
Selon un mode de réalisation, l’invention peut comprendre en outre, en cas d’échec de l’identification du protocole du flux de données par consultation du moteur de signatures, l’application d’une méthode statistique de reconnaissance de protocole afin d’identifier le protocole du flux de données.
Une telle méthode est également consommatrice en ressources de calcul, et n’est pas totalement fiable. Elle est donc avantageusement mise en œuvre en cas d’échec des deux premières méthodes. Elle permet de plus de reconnaître des protocoles chiffrés tels que Bittorrent, qui ne peuvent être reconnus par les deux méthodes précédentes.
Selon un mode de réalisation, le protocole identifié peut être un protocole de niveau applicatif.
Les protocoles de niveau applicatif, et plus généralement les protocoles des couches 5 à 7 du modèle OSI, ne sont pas indiqués explicitement par les couches de niveau inférieur, et le procédé leur est donc avantageusement appliqué selon ce mode de réalisation.
Selon un mode de réalisation, en cas de succès de l'identification du protocole du flux de données par l’analyse grammaticale, le procédé peut comprendre en outre une étape d’identification de données de protocoles par l’application d’un algorithme simple passe à des éléments contextuels du flux de données selon le protocole identifié.
Un tel algorithme est peu consommateur en ressources, et permet ainsi, pour un protocole identifié donné, de différencier les données qu’ils transportent entre différents types de données de protocole.
En complément, en cas d’échec de l’identification de données de protocoles par l’application de l’algorithme simple passe, le procédé peut comprendre en outre la consultation d’un moteur de signatures mettant en correspondance des données de protocoles avec des signatures correspondantes, et l’application séquentielle des signatures au flux de données en vue d’identifier les données de protocole du flux de données.
Ainsi, la méthode d’analyse basée sur les signatures, plus consommatrices en ressources de calcul, est uniquement mise en œuvre en cas d’échec de l’analyse grammaticale, ce qui permet d’optimiser l’utilisation de ressources lors de l’identification implicite de données de protocole.
Selon un mode de réalisation, le procédé peut comprenant en outre une étape de traitement du flux de données sur la base du protocole identifié du flux de données.
Ainsi, un traitement différencié par protocole peut être appliqué.
En complément, traiter le flux de données peut comprendre l’une au moins des étapes parmi :
- appliquer une politique de qualité de service dépendant du protocole identifié ; ou - autoriser ou interdire le flux de données sur la base du protocole identifié.
Un deuxième aspect de l’invention concerne un produit programme informatique comportant des instructions pour la mise en œuvre du procédé selon le premier aspect de l’invention, lorsque ce programme est exécuté par un processeur.
Un troisième aspect de l’invention concerne un dispositif d’identification d’un protocole d’un flux de données échangé entre deux entités d’un réseau de télécommunication, le dispositif comprenant :
- une interface configurée pour recevoir des données du flux de données ;
- un processeur configuré pour :
- mener une analyse grammaticale du flux de données en vue d’identifier un protocole du flux de données ;
- en cas d’échec de l’identification du protocole du flux de données par l’analyse grammaticale, consulter un moteur de signatures mettant en correspondance des protocoles avec des signatures correspondantes, et appliquer séquentiellement les signatures au flux de données en vue d’identifier un protocole du flux de données.
D’autres caractéristiques et avantages de l’invention apparaîtront à l’examen de la description détaillée ci-après, et des dessins annexés sur lesquels:
- la figure 1 illustre une architecture générale d’un système selon un mode de réalisation de l’invention;
- la figure 2 est un diagramme présentant les étapes d’un procédé de traitement selon un mode de réalisation de l’invention ;
- la figure 3 illustre la structure d’un dispositif de traitement de données selon un mode de réalisation de l’invention.
L’invention peut être mise en œuvre dans un dispositif d’identification de protocole tel que l’analyseur 300 illustré sur la figure 1 . Le dispositif d’identification sera présenté plus en détails en référence à la figure 3.
La figure 2 présente les étapes d’un procédé d’identification de protocole selon un mode de réalisation de l’invention. A une étape 200, un ou plusieurs paquets d’un flux sont reçus par le dispositif d’identification, par exemple suite à une interception des paquets par l’analyseur 300 sur le lien de communication 200.
A une étape 201 , un paquet de données reçu peut être identifié pour être associé à un flux existant ou pour créer une nouvelle entrée dans une table répertoriant les flux de données en cours. Par exemple, une adresse IP (et éventuellement un numéro de port) d’une entité source et une adresse IP (et éventuellement un numéro de port) d’une entité destinataire peuvent être prises en compte pour identifier le flux correspondant au paquet. Une telle technique est bien connue et ne sera pas explicité davantage.
L’entité source ou destinataire peut désigner indifféremment un client ou un serveur. Le client peut être un ordinateur portable ou de bureau, une tablette tactile, un Smartphone ou encore tout dispositif électronique comprenant une interface permettant de communiquer dans le réseau 100 ou 110, tel que le réseau Internet par exemple. Selon l’invention, les deux entités communicantes peuvent être dans deux réseaux distincts comme illustré sur la figure 1 ou peuvent appartenir au même réseau.
Les protocoles de couches basses du flux de données peuvent être déterminés à l’étape 201 par reconnaissance explicite. Comme indiqué précédemment, une reconnaissance explicite requiert peu de puissance de calcul en ce que le protocole d’une couche d’un niveau donné peut être indiqué explicitement par la couche du niveau qui lui est directement inférieur.
Ainsi, il peut par exemple être déterminé que le protocole IPv4 ou IPv6 est utilisé à partir de données de la couche Ethernet. De même la couche IP indique si le protocole UDP ou TCP est utilisé.
A partir de l’étape 202, le procédé selon l’invention a pour but d’identifier un protocole qui n’est pas signalé explicitement par les couches de niveaux inférieurs. Une telle identification est donc implicite. A titre d’exemple, la reconnaissance d’un protocole des couches du niveau 5 à 7 du niveau OSI, et en particulier du niveau 7 (application), est considérée.
A une étape 203, le dispositif d’identification met en œuvre une analyse grammaticale des données du flux de données, contenues dans le paquet ou les paquets du flux de données, en vue d’identifier un protocole du flux de données. En effet, certains protocoles de niveau applicatif ont une grammaire aisément identifiable en mettant en œuvre une faible puissance de calcul. C’est par exemple le cas des protocoles SMTP et HTTP. De tels protocoles ont des éléments contextuels utiles à leur reconnaissance. Par exemple, ils utilisent tous les deux un processus de « handshake » pour établissement du flux. D’autres protocoles tels que SSL ou SIP peuvent également être identifiés par reconnaissance de leur grammaire. Il est à noter que statistiquement, 90% des protocoles d’application des flux à classifier peuvent être reconnus par utilisation de l’étape 203. Utiliser en priorité une telle méthode de reconnaissance en premier permet ainsi de reconnaître un grand nombre de protocoles avec une faible puissance de calcul.
A l’étape 203, il est vérifié si le protocole du flux de données a été identifié avec succès par l’analyse grammaticale.
En cas de succès de l’identification du protocole du flux de données par l’analyse grammaticale, le procédé peut comprendre en outre une étape 204 d’identification de données de protocoles (« protocol data » en anglais) par l’application d’un algorithme simple passe (« one pass » ou « single pass » en anglais) à des éléments contextuels du flux de données selon le protocole identifié. L’algorithme simple passe peut dépendre du protocole identifié.
L’identification des données de protocole peut être considérée comme l’identification d’une application ou sous-application d’une couche supérieure à la couche du protocole identifié à l’étape 203. Par exemple, si le protocole identifié comme étant HTTP, la sous-application de couche supérieure, ou données de protocoles, peuvent être des données Facebook™ par exemple.
L’application de l’algorithme simple passe peut consister en l’injection d’éléments contextuels du flux (par exemple, pour HTTP, les éléments contextuels peuvent être des éléments tels que l’URL, User Agent, etc) dans un moteur de règles. On appelle élément contextuel du flux tout élément d’en-tête ou de charge utile (payload) du flux de données. L’utilisation d’un algorithme simple passe est peu coûteux en ressources de calcul et le temps de traitement est fixe et ne dépendant pas du nombre d’entrées.
En réponse à l’injection des éléments contextuels, le moteur de règles peut renvoyer un ensemble de règles qui peuvent être testées sur les données du protocole identifié à l’étape 102 afin d’identifier les données de protocole. Par exemple, après avoir identifié le protocole HTTP à l’étape 202, les données de protocole peuvent être identifiées comme étant des données Facebook™.
A une étape 212, il est vérifié si les données de protocoles ont été identifiées à l’étape 204 au moyen de l’algorithme simple passe. En cas de succès, le procédé se poursuit avec l’étape 205. En cas d’échec, le procédé passe à l’étape 206 décrite ci-après.
Les étapes 204 et 205 sont optionnelles et le procédé peut passer directement de l’étape 203 à 205 en cas d’identification positive à l’étape 203.
Une fois le protocole identifié, et éventuellement les données de protocole, le procédé peut comprendre l’application d’une étape 205 de traitement du flux de données en fonction du protocole identifiée, et éventuellement en fonction des données d’application. Le traitement du flux peut par exemple consister à appliquer une politique de qualité de service dépendant du protocole identifié ou à autoriser ou interdire le flux de données sur la base du protocole identifié, ou peut plus généralement consister à classer le flux en fonction du protocole identifié. La classification peut être transmise à un dispositif de traitement extérieur au dispositif d’identification de protocole.
En cas d’échec de l’identification du protocole du flux de données par l’analyse grammaticale à l’étape 202, le procédé selon l’invention comprend une étape 206 de consultation d’un moteur de signatures mettant en correspondance des protocoles avec des signatures correspondantes. A une étape 207, les signatures sont appliquées séquentiellement au flux de données en vue d’identifier le protocole de niveau applicatif du flux de données. Une telle application séquentielle est plus coûteuse en termes de ressources, et est ainsi avantageusement appliquée uniquement en cas d’échec de l’analyse grammaticale à l’étape 202.
Statistiquement, une telle méthode par recherche de signatures permet d’accéder à la moitié des 10% de protocoles applicatifs qui n’ont pu être identifiés par la méthode d’analyse grammaticale (soit 5% des protocoles). Bien que plus coûteuse en ressources de calcul, la méthode par recherche de signatures demeure néanmoins fiable.
Les étapes 206 et 207 peuvent également être appliquées aux données de protocole en cas d’échec d’identification à l’étape 204. Dans ce cas, les données de protocoles sont comparées avec des signatures pour leur identification.
A une étape 208, il est vérifié si le protocole du flux de données a été identifié avec succès par la méthode de recherche de signatures.
En cas de succès, le procédé reprend à l’étape 205 décrite précédemment.
En cas d’échec, un mode de réalisation de l’invention peut prévoir une étape additionnelle 209 d’application d’une méthode statistique de reconnaissance de protocole afin d’identifier le protocole applicatif du flux de données (ou les données de protocole). Une telle méthode permet notamment d’identifier des protocoles chiffrés, tels que Bittorrent. Une telle méthode est coûteuse en puissance de calculs (recherche séquentielle) et n’est pas totalement fiable. Elle permet toutefois d’identifier 1 à 2% des protocoles ou des données de protocole qui n’ont pas été identifiés par les méthodes mises en œuvre précédemment.
A une étape 210, il est vérifié si le protocole du flux de données a été identifié avec succès par la méthode statistique.
En cas de succès, le procédé reprend à l’étape 205 décrite précédemment.
En cas d’échec (statistiquement dans 3% des cas environs), le procédé s’achève sans pouvoir identifier le protocole applicatif du flux de données. Un traitement prédéfini peut être appliqué à une étape 211 en cas d’échec. Par exemple, par mesure de précaution, le flux de données peut être bloqué.
L’invention prévoit ainsi l’application incrémentale de méthodes de reconnaissances de protocole, de la méthode la plus fiable et la moins coûteuse en puissance de calcul, à la méthode la moins fiable et la plus consommatrice en ressources. Elle optimise ainsi la recherche du protocole de niveau applicatif. La figure 3 représente un dispositif d’identification de protocole 301 selon un mode de réalisation de l’invention.
Le dispositif d’identification 301 peut être implémenté dans l’analyseur 300 situé en interception entre les réseaux 100 et 110 de la figure 1. De manière plus général, il est apte à recevoir des données de flux de données transitant entre deux entités réseau.
Le dispositif d’identification comprend une mémoire vive 305 et un processeur 304, ainsi qu’une mémoire 301 pour stocker des instructions permettant la mise en œuvre des étapes du procédé décrit ci-avant en référence à la figure 2. Le processeur peut comprendre des sous-entités 304.1 à 304.3 respectivement dédiées aux trois méthodes de reconnaissance décrites ci-avant.
La mémoire 301 peut en outre stocker des données utilisées par le processeur pour la mise en œuvre du procédé, notamment :
- le moteur de signatures mettant en correspondance des signatures avec des protocoles correspondants ;
- les ensembles de règles associées à des protocoles données, pour la reconnaissance de données de protocole ;
- des règles de méthodes statistiques de reconnaissance de protocole.
Le dispositif d’identification 301 comporte en outre une interface d’entrée 302 destinée à recevoir les données de flux de données circulant sur le lien de communication 200 ou dans un réseau donné.
Le dispositif d’identification 301 comprend en outre une interface de sortie 303 apte à fournir un résultat d’identification de protocole, ou une commande déterminée à partir du protocole identifié.
Bien entendu, la présente invention ne se limite pas à la forme de réalisation décrite ci-avant à titre d’exemple ; elle s’étend à d’autres variantes.

Claims

REVENDICATIONS
1. Procédé d’identification d’un protocole d’un flux de données échangé entre deux entités (111 ; 112) d’un réseau de télécommunication, le procédé de traitement comprenant les étapes suivantes :
- sur réception (200) de données du flux de données, analyse grammaticale (202) dudit flux de données en vue d’identifier un protocole du flux de données ;
- en cas d’échec (203) de l’identification du protocole du flux de données par l’analyse grammaticale, consultation (206) d’un moteur de signatures mettant en correspondance des protocoles avec des signatures correspondantes, et application séquentielle (207) des signatures au flux de données en vue d’identifier un protocole du flux de données.
2. Procédé selon la revendication 1 , comprenant en outre, en cas d’échec (208) de l’identification du protocole du flux de données par consultation du moteur de signatures, l’application (209) d’une méthode statistique de reconnaissance de protocole afin d’identifier le protocole du flux de données.
3. Procédé selon la revendication 1 ou 2, dans lequel le protocole identifié est un protocole de niveau applicatif.
4. Procédé selon l’une des revendications précédentes, dans lequel, en cas de succès (203) de l’identification du protocole du flux de données par l’analyse grammaticale, le procédé comprend en outre une étape d’identification (204) de données de protocoles par l’application d’un algorithme simple passe à des éléments contextuels du flux de données selon le protocole identifié.
5. Procédé selon la revendication 4, dans lequel, en cas d’échec de l’identification de données de protocoles par l’application de l’algorithme simple passe, le procédé comprend en outre la consultation (206) d’un moteur de signatures mettant en correspondance des données de protocoles avec des signatures correspondantes, et l’application séquentielle (207) des signatures au flux de données en vue d’identifier les données de protocole du flux de données.
6. Procédé selon l’une des revendications précédentes, comprenant en outre une étape de traitement (205) du flux de données sur la base du protocole identifié du flux de données.
7. Procédé selon la revendication 6, dans lequel le traitement (205) du flux de données comprend l’une au moins des étapes parmi :
- appliquer une politique de qualité de service dépendant du protocole identifié ; ou
- autoriser ou interdire le flux de données sur la base du protocole identifié.
8. Produit programme informatique comportant des instructions pour la mise en œuvre du procédé selon l’une des revendications 1 à 7, lorsque ce programme est exécuté par un processeur.
9. Dispositif d’identification d’un protocole d’un flux de données échangé entre deux entités d’un réseau de télécommunication, le dispositif comprenant :
- une interface (302) configurée pour recevoir des données du flux de données ;
- un processeur (304) configuré pour :
- mener une analyse grammaticale du flux de données en vue d’identifier un protocole du flux de données ;
- en cas d’échec de l’identification du protocole du flux de données par l’analyse grammaticale, consulter un moteur de signatures mettant en correspondance des protocoles avec des signatures correspondantes, et appliquer séquentiellement les signatures au flux de données en vue d’identifier un protocole du flux de données.
PCT/FR2019/051682 2018-07-06 2019-07-05 Identification de protocole d'un flux de données WO2020008159A1 (fr)

Priority Applications (5)

Application Number Priority Date Filing Date Title
JP2020572750A JP7412363B2 (ja) 2018-07-06 2019-07-05 データストリームのプロトコルの識別
KR1020207036935A KR20210043498A (ko) 2018-07-06 2019-07-05 데이터 스트림의 프로토콜 식별
CA3103363A CA3103363A1 (fr) 2018-07-06 2019-07-05 Identification de protocole d'un flux de donnees
EP19748867.9A EP3818676A1 (fr) 2018-07-06 2019-07-05 Identification de protocole d'un flux de données
US17/124,724 US11265372B2 (en) 2018-07-06 2020-12-17 Identification of a protocol of a data stream

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR1856240 2018-07-06
FR1856240A FR3083659B1 (fr) 2018-07-06 2018-07-06 Identification de protocole d'un flux de donnees

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US17/124,724 Continuation US11265372B2 (en) 2018-07-06 2020-12-17 Identification of a protocol of a data stream

Publications (1)

Publication Number Publication Date
WO2020008159A1 true WO2020008159A1 (fr) 2020-01-09

Family

ID=65031381

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/FR2019/051682 WO2020008159A1 (fr) 2018-07-06 2019-07-05 Identification de protocole d'un flux de données

Country Status (7)

Country Link
US (1) US11265372B2 (fr)
EP (1) EP3818676A1 (fr)
JP (1) JP7412363B2 (fr)
KR (1) KR20210043498A (fr)
CA (1) CA3103363A1 (fr)
FR (1) FR3083659B1 (fr)
WO (1) WO2020008159A1 (fr)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN114285918A (zh) * 2021-12-30 2022-04-05 湖北天融信网络安全技术有限公司 基于协议分析的分流方法、装置、电子设备及存储介质

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20060106583A1 (en) * 2002-07-29 2006-05-18 Alfortville Fdida Method for protocol recognition and analysis in data networks
EP1722509A1 (fr) 2005-05-13 2006-11-15 Qosmos Analyse du trafic dans les réseaux à haut débit
US20130238782A1 (en) * 2012-03-09 2013-09-12 Alcatel-Lucent Usa Inc. Method and apparatus for identifying an application associated with an ip flow using dns data
EP2916512A1 (fr) * 2014-03-07 2015-09-09 Mitsubishi Electric R&D Centre Europe B.V. Procédé pour classifier une connexion TCP véhiculant un trafic HTTP comme une connexion TCP sécurisée ou non sécurisée

Family Cites Families (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1196856B1 (fr) * 1999-06-30 2011-01-19 Apptitude, Inc. Procede et appareil permettant de surveiller le trafic dans un reseau
US7664048B1 (en) * 2003-11-24 2010-02-16 Packeteer, Inc. Heuristic behavior pattern matching of data flows in enhanced network traffic classification
US8509071B1 (en) * 2010-10-06 2013-08-13 Juniper Networks, Inc. Multi-dimensional traffic management
EP2560338B1 (fr) * 2011-06-13 2016-01-13 Huawei Technologies Co., Ltd. Procédé et appareil permettant une analyse de protocole
WO2013187963A2 (fr) * 2012-03-30 2013-12-19 The University Of North Carolina At Chapel Hill Procédés, systèmes et supports lisibles par un ordinateur permettant un filtrage rapide d'un trafic de données opaque
EP3499908B1 (fr) * 2013-03-15 2021-12-29 Extreme Networks, Inc. Dispositif et procédé destiné à la détermination des applications fonctionnant sur un réseau
US9813447B2 (en) * 2013-03-15 2017-11-07 Extreme Networks, Inc. Device and related method for establishing network policy based on applications
US10560362B2 (en) * 2014-11-25 2020-02-11 Fortinet, Inc. Application control
US20180212998A1 (en) * 2017-01-23 2018-07-26 ShieldX Networks, Inc. Updating computer security threat signature libraries based on computing environment profile information

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20060106583A1 (en) * 2002-07-29 2006-05-18 Alfortville Fdida Method for protocol recognition and analysis in data networks
EP1722509A1 (fr) 2005-05-13 2006-11-15 Qosmos Analyse du trafic dans les réseaux à haut débit
US20130238782A1 (en) * 2012-03-09 2013-09-12 Alcatel-Lucent Usa Inc. Method and apparatus for identifying an application associated with an ip flow using dns data
EP2916512A1 (fr) * 2014-03-07 2015-09-09 Mitsubishi Electric R&D Centre Europe B.V. Procédé pour classifier une connexion TCP véhiculant un trafic HTTP comme une connexion TCP sécurisée ou non sécurisée

Also Published As

Publication number Publication date
JP2021529470A (ja) 2021-10-28
US20210105319A1 (en) 2021-04-08
KR20210043498A (ko) 2021-04-21
JP7412363B2 (ja) 2024-01-12
FR3083659B1 (fr) 2020-08-28
EP3818676A1 (fr) 2021-05-12
CA3103363A1 (fr) 2020-01-09
FR3083659A1 (fr) 2020-01-10
US11265372B2 (en) 2022-03-01

Similar Documents

Publication Publication Date Title
Park et al. Towards automated application signature generation for traffic identification
EP2084854B1 (fr) Procédé d'identification de session multimédia pour des réseaux ip
US9686173B1 (en) Unsupervised methodology to unveil content delivery network structures
FR2924552A1 (fr) Procede de securisation d'un canal bidirectionnel de communication et dispositif de mise en oeuvre du procede
WO2021152262A1 (fr) Procede de surveillance de donnees echangees sur un reseau et dispositif de detection d'intrusions
EP3216189B1 (fr) Délégation d'intermédiation sur un échange de données chiffrées
WO2020008159A1 (fr) Identification de protocole d'un flux de données
EP3375143B1 (fr) Analyse asynchrone d'un flux de données
Dubin et al. Video quality representation classification of encrypted http adaptive video streaming
EP3533201A1 (fr) Système pour hiérarchiser les applications informatiques mises en oeuvre par un groupe d'utilisateurs
Yoon et al. Header signature maintenance for Internet traffic identification
WO2000036779A2 (fr) Dispositf et procede de traitement d'une sequence de paquets d'information
EP1743453A1 (fr) Mesure de performance dans un reseau de transmission de paquets
WO2011144880A1 (fr) Procédé et dispositif d'analyse de données interceptées sur un réseau ip pour la surveillance de l'activité des utilisateurs d'un site web
EP2171966B1 (fr) Gestion de sessions multi-flux entre un terminal et un serveur
EP3146681B1 (fr) Procédé de distribution pour une liaison à liens multiples et hétérogènes
WO2016151311A1 (fr) Procédés et appareil de traitement de données dans un réseau
WO2023036846A1 (fr) Procédé et système d'analyse de flux de données
CA3226756A1 (fr) Procede et systeme d'analyse de flux de donnees
EP4187446A1 (fr) Procédés d'entraînement et d'utilisation d'un réseau de neurones artificiels pour identifier une valeur de propriété, et système associé
WO2009004234A1 (fr) Detection d'anomalie dans le trafic d'entites de service a travers un reseau de paquets
WO2010052406A1 (fr) Procede d'observation de flots transmis a travers un reseau de communication par paquets
WO2006054032A1 (fr) Procede et systeme de mesure de l'usage d'une application

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: 19748867

Country of ref document: EP

Kind code of ref document: A1

ENP Entry into the national phase

Ref document number: 3103363

Country of ref document: CA

ENP Entry into the national phase

Ref document number: 2020572750

Country of ref document: JP

Kind code of ref document: A

NENP Non-entry into the national phase

Ref country code: DE