FR3083659A1 - Identification de protocole d'un flux de donnees - Google Patents
Identification de protocole d'un flux de donnees Download PDFInfo
- Publication number
- FR3083659A1 FR3083659A1 FR1856240A FR1856240A FR3083659A1 FR 3083659 A1 FR3083659 A1 FR 3083659A1 FR 1856240 A FR1856240 A FR 1856240A FR 1856240 A FR1856240 A FR 1856240A FR 3083659 A1 FR3083659 A1 FR 3083659A1
- Authority
- FR
- France
- Prior art keywords
- protocol
- data
- data flow
- identify
- signatures
- 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.)
- Granted
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
Abstract
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é 112 (de type client par exemple) connecté à un second réseau 110 comprenant une deuxième entité 111 (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 110. Le trafic entre les réseaux 100 et 110 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 l’é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 (9)
- REVENDICATIONS1. 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.
Priority Applications (7)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| FR1856240A FR3083659B1 (fr) | 2018-07-06 | 2018-07-06 | 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 |
| PCT/FR2019/051682 WO2020008159A1 (fr) | 2018-07-06 | 2019-07-05 | Identification de protocole d'un flux de données |
| KR1020207036935A KR20210043498A (ko) | 2018-07-06 | 2019-07-05 | 데이터 스트림의 프로토콜 식별 |
| JP2020572750A JP7412363B2 (ja) | 2018-07-06 | 2019-07-05 | データストリームのプロトコルの識別 |
| CA3103363A CA3103363A1 (fr) | 2018-07-06 | 2019-07-05 | Identification de protocole d'un flux de donnees |
| 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 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| FR3083659A1 true FR3083659A1 (fr) | 2020-01-10 |
| FR3083659B1 FR3083659B1 (fr) | 2020-08-28 |
Family
ID=65031381
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| FR1856240A Active FR3083659B1 (fr) | 2018-07-06 | 2018-07-06 | Identification de protocole d'un flux de donnees |
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)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN114285918A (zh) * | 2021-12-30 | 2022-04-05 | 湖北天融信网络安全技术有限公司 | 基于协议分析的分流方法、装置、电子设备及存储介质 |
Citations (4)
| 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)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN1293502C (zh) * | 1999-06-30 | 2007-01-03 | 倾向探测公司 | 用于监控网络流量的方法和设备 |
| 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 |
| WO2012171166A1 (fr) * | 2011-06-13 | 2012-12-20 | 华为技术有限公司 | Procédé et appareil permettant une analyse de protocole |
| US9973473B2 (en) * | 2012-03-30 | 2018-05-15 | The University Of North Carolina At Chapel Hill | Methods, systems, and computer readable media for rapid filtering of opaque data traffic |
| US9813447B2 (en) * | 2013-03-15 | 2017-11-07 | Extreme Networks, Inc. | Device and related method for establishing network policy based on applications |
| EP2974355B1 (fr) * | 2013-03-15 | 2019-02-13 | Extreme Networks, Inc. | Dispositif et procédé associé destiné à une règle et mise en miroir de trafic dynamique et détermination d'application fonctionnant sur un réseau |
| 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 |
-
2018
- 2018-07-06 FR FR1856240A patent/FR3083659B1/fr active Active
-
2019
- 2019-07-05 JP JP2020572750A patent/JP7412363B2/ja active Active
- 2019-07-05 WO PCT/FR2019/051682 patent/WO2020008159A1/fr unknown
- 2019-07-05 CA CA3103363A patent/CA3103363A1/fr active Pending
- 2019-07-05 KR KR1020207036935A patent/KR20210043498A/ko unknown
- 2019-07-05 EP EP19748867.9A patent/EP3818676A1/fr active Pending
-
2020
- 2020-12-17 US US17/124,724 patent/US11265372B2/en active Active
Patent Citations (4)
| 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 |
|---|---|
| WO2020008159A1 (fr) | 2020-01-09 |
| JP7412363B2 (ja) | 2024-01-12 |
| US11265372B2 (en) | 2022-03-01 |
| FR3083659B1 (fr) | 2020-08-28 |
| KR20210043498A (ko) | 2021-04-21 |
| JP2021529470A (ja) | 2021-10-28 |
| US20210105319A1 (en) | 2021-04-08 |
| EP3818676A1 (fr) | 2021-05-12 |
| CA3103363A1 (fr) | 2020-01-09 |
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 | |
| JP4955107B2 (ja) | Ｉｐネットワーク内のトラフィックを分類するための方法およびユニット | |
| 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 | |
| Mazhar Rathore et al. | Exploiting encrypted and tunneled multimedia calls in high-speed big data environment | |
| EP2767060B1 (fr) | Passerelle, et procédé, programme d'ordinateur et moyens de stockage correspondants | |
| WO2020008159A1 (fr) | Identification de protocole d'un flux de données | |
| EP3216189B1 (fr) | Délégation d'intermédiation sur un échange de données chiffrées | |
| EP3375143B1 (fr) | Analyse asynchrone d'un flux de données | |
| Dubin et al. | Video quality representation classification of encrypted http adaptive video streaming | |
| WO2018078293A1 (fr) | Système pour hiérarchiser les applications informatiques mises en œuvre par un groupe d'utilisateurs | |
| Yoon et al. | Header signature maintenance for Internet traffic identification | |
| EP4009584A1 (fr) | Procédé de détermination de classifieurs pour la détection d'attaques dans un réseau de communication, dispositif de détermination associé | |
| 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 | |
| WO2016151311A1 (fr) | Procédés et appareil de traitement de données dans un réseau | |
| 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é | |
| 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 | |
| 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 | |
| FR3021481A1 (fr) | Procede de distribution pour une liaison a liens multiples et heterogenes |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PLFP | Fee payment |
Year of fee payment: 2 |
|
| PLSC | Publication of the preliminary search report |
Effective date: 20200110 |
|
| PLFP | Fee payment |
Year of fee payment: 3 |
|
| PLFP | Fee payment |
Year of fee payment: 4 |
|
| PLFP | Fee payment |
Year of fee payment: 5 |
|
| PLFP | Fee payment |
Year of fee payment: 6 |