METHOD AND SYSTEM FOR ANALYSIS OF DATA STREAMS
Patent Information
- Application Number
- DE602022015258
- Authority / Receiving Office
- DE · DE
- Patent Type
- Patents
- Current Assignee / Owner
- Priority Date
- 2021-09-07
- Filing Date
- 2022-09-07
- Publication Date
- 2025-05-28
- Estimated Expiration
- 2042-09-07
AI Technical Summary
Existing network monitoring and traffic management solutions, including hardware-based network probes and software-based Packet Sampling methods, struggle to efficiently process high-speed data streams and identify complex protocol chains, especially those involving tunneled, multiplexed, or encrypted communications.
A method that analyzes data streams by classifying protocols through explicit detection, session detection, and deep packet inspection, using a dynamic decision tree and a dynamic session database to identify protocol chains and calculate session fingerprints, which are then recorded in a hash table for further analysis.
This approach allows for efficient identification of protocol layers, including those not announced, and maintains accurate analysis even at high speeds, reducing the risk of information loss and cascading errors, while supporting complex protocol sequences and encryption variations.
Description
[0001] Technological developments in networking have led to an increase in network speeds beyond the capabilities of network monitoring and traffic management equipment used. Known network monitoring and traffic management equipment typically includes network probes, which are designed to monitor a data stream received over a communications network.
[0002] In practice, network probes are designed to process a fixed stream of data and monitor specific metrics of that data. As a result, whenever the data flow increases and / or a new data flow metric is identified for monitoring, these network probes must be redesigned to modify their processing capabilities to handle the changed stream of data.
[0003] To mitigate the inefficiencies associated with hardware network probes, software-based network monitoring and traffic management solutions are known in which Deep Packet Inspection (DPI) is performed on only a few packets. This technical solution is called Packet Sampling (i.e., taking completely random packets from a network flow to sample them). Such a known solution avoids high processing overhead and higher network latencies. However, such a previous solution is not entirely satisfactory, because the analysis is performed restrictively on protocol chains or communication sessions comprising five fixed fields (source field, destination field, source port, destination port, communication protocol).As a result, such an analysis according to the prior art does not allow processing of chains or protocol sessions whose identification base is based on a 5-tuple value (source IP, Destination IP, Source Port, Destination Port and application), nor on delayed detection tunneling protocols, nor in layers 2 to 7 of the Open Systems Interconnection (OSI) model.
[0004] We also know another solution such as that presented by the document EP 1 788 490 A (APPTITUDE INC), teaching an architecture based on the implementation of a specific hardware part FPGA and ASICs, and a software part involving packet slicing.
[0005] According to the solution described in EP 1 788 490 A, the payload or attached content of a protocol layer is at least partly stored in memory first in the FPGA, then delegated to the processor and RAM. The hardware architecture does not allow the state of a session to be retained for a sufficiently long time. The system is significantly slowed down when analyzing a high-speed data stream and prevents a posteriori identification of the protocols. In addition, since the FPGA has limited memory, it must empty its cache periodically, which results in the loss of information and data packets, and can lead to inaccurate analysis statistics. In addition, the use of packet slicing, reassembly for analysis therefore involves a risk of loss of information.Furthermore, managing the table of digital fingerprints calculated on the basis of five tuples (source IP address / a port number, a destination IP address / port number and the protocol used) implies the identification of a session on the basis of a digital fingerprint calculation taking into account only a single layer of identification whereas in the case of sessions built on several tunneled or multiplexed protocols, the encapsulation creates several hidden sessions that become impossible to identify with a 5-tuple. In addition, the encryption of communications adds variation that will also distort comparisons with a database of malware digital fingerprints. Finally, the solution according to EP 1 788 490 takes into account the payload in the calculation of the hash which will lead to too many variations in the analysis values to remain relevant in the context of a comparison, and the 5-tuple calculation approach.
[0006] Moreover, at very high throughput, the use for the calculation of the digital fingerprint or hash according to a 5-tuple method combining hardware techniques (FPGA or ASIC) and Packet Slicing (slicing the packet on lower or higher layers) to accelerate the processing of packets, natively causes a loss of visibility and cascading errors.
[0007] Furthermore, the 5-tuple approach for two sessions having the same 5-tuple, but whose lower layer is different, (i.e., a different virtual network) will be interpreted as if the two sessions are identical when this is not the case, and then results in a loss of information that can seriously affect the data analysis results.
[0008] The term "hash" is subsequently used to refer to a calculated digital fingerprint.
[0009] The present invention overcomes the drawbacks and improves the situation.
[0010] The present invention relates to a method for analyzing a data stream of data packets received via a communication network, the data stream comprising batches of packets each defined by a chain of communication protocols attached to at least one session.
[0011] According to a general definition of the invention, the method comprises an analysis of protocols according to the following steps: analyzing the first protocol Pi of a chain of communication protocols according to a step of classification by explicit detection configured to check whether the first protocol Pi announces the next communication protocol Pi+1 of the chain of protocols: in the case of announcement, the next protocol Pi+1 thus announced is identified; while in the case of non-announcement, analyzing the next protocol Pi+1 according to a step of classification by session detection; analyzing according to a step of classification by session detection, configured to check whether the protocol Pi+1 is attached to a known chain of protocols according to a dynamic decision tree by querying a dynamic session database comprising identified chains of protocols: in the case of attachment, the protocol Pi+1 is identified, and the protocol Pi+2 is analyzed by repeating the steps of classification by explicit detection, of classification by session detection;while in case of no attachment, analyzing the Pi+1 protocol according to a deep packet inspection classification step; analyzing the Pi+1 protocol according to a deep packet inspection classification step, configured to identify the communication protocol of the Pi+1 packet according to a dynamic decision tree correlated to a knowledge database comprising protocol analysis parameters and a marker base specific to each known protocol;in case of failure to identify the protocol Pi+1, issue a list of candidates of potential protocols to be taken into account according to at least two detection branches, each detection being attached to a determined sub-session to analyze the following protocol(s) Pi+n with n>_2 by repeating the steps of classification by explicit detection, classification by session detection, and classification by deep packet inspection until at least one protocol whose identity is certain is identified; in case of identification of a protocol Pi+n whose identity is certain on a detection branch, retroactively validate the detection branch, and discard the remaining unvalidated detection branches; in case of failure to identify a protocol Pi+n whose identity is certain on a detection branch, classify the protocol Pi+1 as unknown retroactively;and associate a label with the data packets based on each session for which the protocols have been identified. ;
[0012] It should be noted that the analysis of the binary characteristics of each packet of a communication session (or protocol chain) is implemented according to the invention until it is possible (or not) to determine (identify) the protocol used in this session.
[0013] Such an approach according to the invention has the advantage of allowing a higher labeling rate than previous approaches, insofar as it can be executed from layer 2 to layer 7 of the OSI model, in a single packet analysis pass. It also allows protocol chains to be identified in the case of tunneling protocols, or delayed detection protocols as well as continuous detection, and this, even if a protocol is not identified immediately, the detection of the following protocols continues.
[0014] Additionally, by using the dynamic session database storing previously identified communication sessions, the present invention is faster than prior solutions based on all packet inspection.
[0015] According to another aspect of the invention, the method further comprises, after each classification step, a step of calculating a session fingerprint from a chosen hash function, said session fingerprint being calculated on the basis of the first identified protocol, and on the previously calculated digital fingerprint of the already identified protocol chain without taking into account the attached content, each digital fingerprint being calculated on the basis of parameters (or tuple) chosen and specific to each type of protocol, each type of protocol having its own number of defined markers;and a step of recording the session digital fingerprint calculated after each protocol identification step following the step of classifying each protocol by deep packet inspection or after the retroactive validation step, in a hash table integrated in the dynamic session database, each digital fingerprint being linked to at least one chosen session, said digital fingerprints calculated after each step of classifying each protocol by deep packet inspection being able to be updated retroactively in the event of delayed identification of a protocol according to the verification step.;
[0016] Advantageously, the Applicant observed that the dynamic management of digital fingerprints according to the invention allows the digital fingerprint of an unvalidated protocol to be updated a posteriori, this evolving as the packet is read.
[0017] This unique algorithm allows all types of protocols to be detected with a single probe, including, but not limited to, simple, complex, tunneled and multiplexed protocol sequences.
[0018] The management of digital fingerprints of the method according to the invention also has the advantage of avoiding a step of cutting the protocol chain (slicing in English) and thus eliminating the risk of loss of information, and also makes it possible to obtain truly unique identifiers on the protocol chain, regardless of the length of said protocol chain which makes up the packet(s).
[0019] In practice, in the event of detection of tunneled, multiplexed, multichannel protocols detected with certainty, the method according to the invention comprises the following sub-steps: Generate at least one detection branch per verified protocol to be taken into account for subsequent detection, Calculate a session fingerprint from a hash function chosen for each detection branch, each detection branch being attached to a determined sub-session to analyze the following protocol(s) Pi+n; and Record the session fingerprint of each detection branch attached to a protocol chain, the recording step being configured to assign a unique identifier to each detection branch of the detected tunneled, multiplexed, or multi-channel protocol(s).
[0020] Advantageously, the method according to the invention makes it possible to obtain a unique digital fingerprint per channel, or branch of detected protocols, and thus avoid a loss of information such as two channels having the same identifier.
[0021] For example, the hash table is updated if detecting at least one protocol in a session requires implementing delayed detection across multiple packets.
[0022] In practice, the knowledge database comprises a static knowledge database, wherein the static knowledge database comprises markers based on empirical knowledge of the characteristics of the protocols, and wherein the empirical knowledge comprises algorithmic means of detecting protocols based on location standards, logical links between communication protocols, queries for comments and frequency patterns of the communication protocols.
[0023] Further, the method according to the invention comprises performing data analysis followed by data extraction for the data packets based on the associated label.
[0024] According to a first embodiment of the invention, the execution of the protocol analysis and the execution, analysis and extraction of the data for a data packet are performed dynamically on a single processing core of a multi-core processor.
[0025] According to a second embodiment of the invention, the execution of the analysis and the extraction of the data for the data packet are performed on several processing cores of a multi-core processor.
[0026] In practice, the method according to the invention comprises separating the data stream into a plurality of processing queues in which protocol analysis followed by data analysis and extraction are performed on data packets in each of the processing queues.
[0027] Further, the separation of the data flow into the plurality of processing queues is based on a receiving-side scaling RSS algorithm.
[0028] According to one embodiment of the method according to the invention, the protocol analysis is executed dynamically on layers 2 to 7 of the OSI layer model.
[0029] The invention also relates to a computer system for analyzing a data flow of data packets received via a communication network, the data flow comprising batches of packets each defined by a chain of communication protocols attached to at least one session.
[0030] According to another general definition of the invention, the system comprises a processor comprising at least one processing core for processing a predetermined number of data packets per minute and a protocol analysis engine on at least one processing core, wherein the protocol analysis engine: analysis of the first protocol of a chain of communication protocols according to a classification step by configured explicit detection? To check whether the first protocol announces the following communication protocol of the chain of protocols, in the event of an announcement, the following protocol thus announced is identified, while in the event of no announcement, the analysis engine is able to analyze the protocol according to a classification step by session detection;analysis according to a classification step by session detection, configured to check whether the protocol Pi+1 is attached to a known protocol chain according to a dynamic decision tree by querying a dynamic session database comprising identified protocol chains: in the event of attachment, the protocol Pi+1 is identified, and the analysis engine is able to analyze the protocol Pi+2 by repeating the classification steps by explicit detection, classification by session detection; while in the event of no attachment, the analysis engine is able to analyze the protocol Pi+1 according to a classification step by deep packet inspection;analyzes the protocol Pi+1 according to a deep packet inspection classification step, configured to identify the communication protocol of the packet Pi+1 according to a dynamic decision tree correlated to a knowledge database comprising protocol analysis parameters and a base of markers specific to each known protocol; in the event of failure to identify the protocol Pi+1, the analysis engine is able to emit a list of candidates of potential protocols to be taken into account according to at least two detection branches, each detection being attached to a determined sub-session to analyze the following protocol(s) Pi+n with n>_2 by repeating the steps of classification by explicit detection, classification by session detection, and classification by deep packet inspection until at least one protocol whose identity is certain is identified;in the event of identification of a Pi+n protocol whose identity is certain on a detection branch, the analysis engine is able to retroactively validate the detection branch, and discard the remaining unvalidated detection branches; in the event of absence of identification of a Pi+n protocol whose identity is certain on a detection branch, the analysis engine is able to classify the Pi+1 protocol as unknown retroactively; and a labeling engine able to associate a label with the data packets according to the protocols thus identified. ;
[0031] In practice, the protocol analysis engine: calculates a session fingerprint from a hash function chosen after each classification step, said fingerprint being calculated on the basis of the first identified protocol, and on the previously calculated fingerprint of the already identified protocol chain without taking into account the attached content, each fingerprint is calculated on the basis of parameters (or tuple) chosen and specific to each type of protocol, each type of protocol having its own number of defined markers (n-Tuples);records the session fingerprint calculated after each protocol identification step following the classification step of each protocol by deep packet inspection or after the retroactive validation step, in a hash table integrated into the dynamic session database, each digital fingerprint being linked to at least one chosen session, said digital fingerprints calculated after each classification step of each protocol by deep packet inspection being able to be updated retroactively in the event of delayed identification of a protocol according to the verification step. ;
[0032] The protocol analysis engine of the system according to the invention further comprises, in the event of detection of tunneled, multiplexed, multichannel, or multiplexed multichannel protocols detected with certainty, Generates at least one detection branch per verified protocol to be considered for subsequent detection, Calculates a session fingerprint from a hash function chosen for each detection branch, each detection branch being attached to a determined sub-session to analyze the following protocol(s); and Records the session fingerprint of each detection branch attached to a protocol chain, the recording being configured to assign a unique identifier to each detection branch of the detected tunneled, multiplexed, or multi-channel protocol(s).
[0033] The system according to the invention further comprises a knowledge database comprising a static knowledge database in which the static knowledge database comprises markers, also called labels, based on empirical knowledge of the characteristics of the protocols, and in which the empirical knowledge comprises algorithmic means for detecting protocols based on standards on location, logical links between the communication protocols, requests for comments and frequency patterns of the communication protocols.
[0034] In practice, the system according to the invention comprises a content analysis engine executable on at least one processing core to analyze and extract the data packet based on the associated label.
[0035] According to one embodiment of the invention, the protocol analysis engine and the content analysis engine consecutively perform protocol analysis followed by data analysis and extraction for the data stream of data packets, and wherein the content analysis engine separately performs data analysis and extraction for differently labeled data packets.
[0036] The system further includes a network interface card coupled to the processor, wherein the network card separates the data stream of data packets into a plurality of processing queues, and wherein the protocol analysis engine and the content analysis engine perform packet analysis and data extraction from the packets on each of the plurality of processing queues.
[0037] ÀFor example, the network interface card (NIC) separates the data stream from the data packets based on the RSS scaling algorithm on the receiving side.
[0038] The method and system according to the invention advantageously make it possible to identify protocol layers that have not been announced. In the case where these protocols do not announce themselves, or do not announce those that follow, and make it possible to search for a set of markers likely to validate the identification of a particular protocol.
[0039] Advantageously, the system and method according to the invention also make it possible to carry out a validation by multiple and logical bounces of the analyzed protocols if a layer decreed as "safe" is validated, said "safe" layer thus making it possible to validate all of the classification choices made. In other words, the preceding stacks of protocols can be deduced correctly.
[0040] Surprisingly, the method and system according to the invention make it possible to wait for several packets to validate a protocol stacking chain for a given session, and to be able to maintain session uniqueness per branch while guaranteeing a unique digital fingerprint per session and per detection branch by carrying out continuous digital fingerprint calculations on each layer of protocols contained in a packet.
[0041] Finally, the method and system according to the invention make it possible to maintain a very deep granularity of the analysis of network data, and thus limit protocol identification errors and guarantee reliable analysis data. BRIEF DESCRIPTION OF THE DRAWINGS
[0042] There Figure 1illustrates a computer system for analyzing a data stream of data packets received via a communications network, in accordance with an exemplary implementation of the present invention, The Figure 2 illustrates the diagrams of the computer system, in accordance with an exemplary implementation of the present invention, The Figure 3 illustrates the computer system for analyzing a data stream of data packets received via a communications network, in accordance with an exemplary implementation of the present invention, The Figure 4 illustrates the flow of events within a processing core of the computer system, in accordance with an exemplary implementation of the present invention, The Figure 5 illustrates the step of receiving and distributing packets by a network interface card in accordance with the invention, The figures 6 , 7 And 8illustrate the steps of analyzing a data stream of data packets received via a communications network, in accordance with an exemplary implementation of the present invention, and figures 9 , 10 And 11 illustrate examples of linear analysis in accordance with the invention; The figures 12 , 13 , And 14 illustrate an example of analysis applied to a detection of delayed detection protocols in accordance with the invention; The Figure 15 illustrates an example of analysis applied to protocol detection with management of an associated hash table in accordance with the invention; The figures 16 And 17 illustrate the management of digital fingerprints during detection in accordance with the invention; and The figure 18 illustrates an example of analysis applied to the detection of multiplexed and multichannel protocols with management of an associated hash table in accordance with the invention.
[0043] OthersAdvantages and characteristics of the invention will appear on examining the description and the drawings. DETAILED DESCRIPTION
[0044] The above techniques are described in more detail with reference to the figures 1 to 18 . It should be noted that the description and figures only illustrate the principles of the present subject matter and the examples described herein and should not be construed as a limitation to the present subject matter. It is therefore understood that various arrangements may be devised which, although not explicitly described or shown herein, the following statements of principles, aspects and implementations of the present subject matter, and specific examples thereof, are intended to encompass equivalents thereof.
[0045] There Figure 1illustrates a computer system 100 for analyzing a data stream of data packets received via a communications network (not shown), in accordance with an example of the present invention. The computer system 100 may be either a stand-alone computer or a combination of multiple computer systems operating together in a distributed computing environment. Examples of the computer system 100 may include, but are not limited to, desktop computers, laptop computers, and smartphones, as well as personal digital assistants (PDAs).
[0046] The communications network may be a wireless or wired network, or a combination thereof. The communications network may be a collection of individual networks, interconnected with each other and operating as a single large network. Examples of such individual networks include, but are not limited to, the Global System for Mobile Communications (GSM) network, the Universal Mobile Telecommunications System (UMTS) network, the Long Term Evolution (LTE) network, the Personal Communications Services (PCS) network, the Time Division Multiple Access (CDMA) network, the Code-Division Multiple Access (CDMA) network, the Next Generation Network (NGN), the Public Switched Telephone Network (PSTN), and the Integrated Services Digital Network (ISDN).According to the terminology, the communication network includes various network entities, such as gateways and routers; however, these details have been omitted to maintain brevity of description.
[0047] It should be noted that, although the following provisions are provided with respect to the computer system 100, the exemplary implementations of the present invention may also be implemented on various devices or networks used by a network service provider, providing network connectivity to one or more subscribers, such as government organizations, multinational corporations, companies, enterprises, and other establishments. The network service provider may serve as a connection channel between the communication network and the computing devices of its subscribers. It should be noted that the network service provider may implement various other equipment, devices, network nodes interconnected by one or more wired or wireless network links to provide network connectivity to the subscribers.Network nodes may typically include switches, routers, access points, and data links that may facilitate communication between various subscriber hosts (e.g., server computers, client computers, mobile devices, etc.) that may produce and consume data traffic. In another example, the examples may be implemented on various network devices used by individual establishments / organizations, providing network connectivity and security to one or more of its users.
[0048] In reference to the figures 1 to 18, the computing system 100 may include a processor 102, where the processor 102 includes at least one processing core 104. The computing system 100 may further include a protocol parsing engine 106 and a tagging engine 108. In one example, the protocol parsing engine 106 and the tagging engine 108 may be executable on at least one processing core 104.
[0049] The term “analysis engine 106” will be used to refer to the term “protocol analysis engine 106”.
[0050] The processor 102 includes at least one processing core 104 configured to process a predetermined number of data packets per minute and a protocol analysis engine 106 on at least one processing core 104.
[0051] In an exemplary implementation, the protocol analysis engine 106 analyzes the data stream comprising batches of packets each defined by a chain of communication protocols attached to at least one session. Said protocol analysis engine 106 is configured to analyze the first protocol Pi of a chain of communication protocols according to a classification by explicit detection S10, S11, S12, S13 to verify whether said first packet Pi announces the communication protocol of the following data packet Pi+1 of the chain of protocols.
[0052] If announced, the protocol of the next packet, thus announced, is identified S 100.
[0053] In the event of non-announcement, the analysis engine 106 is capable of analyzing the following packet Pi+1 to check whether it is attached to a known protocol chain stored in the dynamic database BDDS comprising protocol chains already identified, according to a classification by session detection S20, S21, S22.
[0054] The protocol analysis engine 106 is configured to apply a session detection classification method S20 consisting of verifying whether the protocol Pi+1 is attached to a known protocol chain according to a dynamic decision tree by querying a dynamic session database BDDS comprising identified protocol chains.
[0055] In practice, the computer system 100 is further coupled to the knowledge database 110 on the data packets comprising a dynamic BDDS stage suitable for storing the sessions, as will be described in more detail below, and a BDC stage suitable for storing knowledge relating to the protocols. It should be noted that if the knowledge database 110 on the data packets has been illustrated as thus distinct from the computer system 100, the knowledge database 110 on the data packets may also be hosted in the computer system 100 depending on its capabilities.
[0056] In the event of attachment, the protocols of the known protocol chain are identified (step S100), the protocol Pi+1 is identified, and the analysis engine 106 is able to analyze the protocol Pi+2 by repeating the steps of classification by explicit detection S10, of classification by session detection S20.
[0057] In case of no attachment, the analysis engine 106 is able to analyze the following protocol Pi+1 according to a classification by deep packet inspection S40, S42, S44, S46.
[0058] According to a classification by deep packet inspection S40, the analysis engine 106 is configured to identify the communication protocol of the packet Pi+1 according to a dynamic decision tree correlated to a knowledge database BDC comprising protocol analysis parameters and a base of specific markers, also called labels (see Figure 11 And Figure 15 ) to each known protocol.
[0059] In the event of failure to identify the protocol Pi+1, the analysis engine 106 is capable of issuing a list of candidates of potential protocols to be taken into account according to at least two possible detection branches, each detection being attached to a determined sub-session to analyze the following protocol(s) Pi+n with n>_2 by repeating the analyses according to the classification by explicit detection S10, by session detection S20, and by deep packet inspection S40 until at least one protocol whose identity is certain is identified.
[0060] In the event of identification of a Pi+n protocol whose identity is certain by the analysis engine 106, on a detection branch, said analysis engine 106 is capable of retroactively validating S60 the detection branch, and of discarding the other remaining unvalidated detection branches.
[0061] In the event of the absence of identification of a Pi+n protocol whose identity is certain on a detection branch, the analysis engine 106 is able to classify the Pi+1 protocol as unknown S60 retroactively and continue the analysis of the following data packets.
[0062] The protocol analysis engine 106 is further capable of calculating a session digital fingerprint Hi+n from a hash function chosen after each classification step S10, S20, S40, said digital fingerprint Hi+n being calculated on the basis of the first identified protocol, and on the previously calculated digital fingerprint Hi+n-1 of the already identified protocol chain without taking into account the attached content or payload.
[0063] Each digital fingerprint Hi+n is thus calculated on the basis of parameters or tuples chosen and specific to each type of protocol, each type of protocol having its own number of defined tuples, i.e. n-Tuples.
[0064] For each protocol, a choice of relevant parameters is made dynamically, thus allowing complete sessions to be managed outside of TCP / UDP.
[0065] The analysis engine 106 is then able to record the session digital fingerprint Hi+n calculated after each protocol identification step following step S40 or after the retroactive validation step S60, in a hash table integrated into the dynamic session database BDDS, each digital fingerprint Hi+n being linked to at least one chosen session, said digital fingerprints Hi+n calculated after each step of classification of each protocol by deep packet inspection S40 being able to be updated retroactively in the event of delayed identification of a protocol according to the verification step S60.
[0066] In practice, when the analysis engine 106 does not identify a protocol Pi+1, and emits a list of candidates of potential protocols to be taken into account according to at least two possible detection branches B1, B2 for delayed detection, each detection being attached to a determined sub-session to analyze the following protocol(s) Pi+n with n>_2 by repeating the analyses according to the classification by explicit detection S10, by session detection S20, and by deep packet inspection S40 until at least one protocol whose identity is certain is identified, the analysis engine 106 calculates a session digital fingerprint Hi+n from a chosen hash function, for each detection branch B1, B2 being attached to a determined sub-session to analyze the following protocol(s) Pi+n.
[0067] The Hi+n session fingerprints thus calculated allow the a posteriori identification of one or more previously unidentified protocols, even if the detection of the session requires several packets, the hash table can be updated to take into account these new elements and thus never lose a single packet or associated data.
[0068] Furthermore, the analysis engine 106 records the session fingerprint Hi+n of each detection branch B1, B2 attached to a protocol chain, the recording being configured to assign a unique identifier to each detection branch.
[0069] In reference to the figure 8, for example, the digital fingerprints H1, H2, and H3 are calculated respectively after identifying the protocols Pi, Pi+1, and Pi+2 of the protocol chain, and when the classification according to a deep packet inspection S40 fails to identify the protocol Pi+1, a digital fingerprint H2T is calculated, and in the case where the identification of the protocol Pi+3 validates the protocol chain, and Pi+1 can be deduced, then Pi+1 is validated and the digital fingerprint H2T is updated by calculating and recording a new digital fingerprint H2.
[0070] According to a particular embodiment of the invention, the analysis engine 106, in the event of detection of tunneled, multiplexed, or multichannel protocols detected with certainty, is capable of generating at least one detection branch A1, A2, B1, B2, C1, C2 per verified protocol to be taken into account for subsequent detection.
[0071] For each generated detection branch A1, A2, B1, B2, C1, C2, the analysis engine 106 calculates a session digital fingerprint Hi+n from a chosen hash function, each detection branch being attached to a determined sub-session to analyze the following protocol(s) Pi+n; and Records the Hi+n session fingerprint of each detection branch attached to a protocol chain, with the record configured to assign a unique identifier to each detection branch of the detected tunneled, multiplexed, or multichannel protocol(s).
[0072] Advantageously, the calculated hash evolves as the data packet is read, making it possible to analyze and detect all protocols with a single probe (i.e. simple, complex, tunneled, multi-channel and multiplexed chains), and thanks to this repetition of hash calculation, on each layer, each of the identifiers is truly unique, regardless of the length of the protocol chain that makes up the packet(s).
[0073] The system 100 further comprises the labeling engine 108, capable of associating a label with the data packets according to the protocols thus identified.
[0074] The analysis engine 106 is able to record the session state if the current session is unknown with a digital fingerprint calculated with n-tuples S31, 32 and S33.
[0075] There Figure 2illustrates the diagrams of the computer system 100 for analyzing the data flow of data packets received via the communication network, in accordance with an exemplary implementation of the present invention.
[0076] As already described, the computer system 100 may include the processor 102, or the processor 102 may include multiple processing cores 104-1, 104-2, 104-3, ..., 104-n. The functions of the functional block labeled as "processor(s)", may be provided by the use of dedicated hardware as well as hardware capable of executing instructions. When provided by a processor, the functions may be provided by a single dedicated processor, by a single shared processor, or by a plurality of individual processors, some of which may be shared.Furthermore, explicit use of the term “processor” would not be construed to refer exclusively to hardware capable of executing instructions and may implicitly include, but not be limited to, digital signal processor (DSP) hardware, network processor, application-specific integrated circuit (ASIC), field programmable gate array (FPGA), read-only memory (ROM) for storing instructions, random access memory (RAM), non-volatile storage. Other hardware, both standard and / or custom, may also be included.
[0077] The computer system 100 may further include a memory 202 coupled to the processor 102, where the memory 202 may include any computer-readable medium, including, for example, volatile memory (e.g., RAM) and / or non-volatile memory (e.g., EPROM, flash memory, etc.).
[0078] Further, the computer system 100 may include a network interface card (NIC) 204 coupled to the processor 102 and the memory 202. The network card 204 may be an integrated component of the computer system 100 or may be a separate component, externally coupled to the computer system 100.
[0079] The computer system 100 may further include the engines 206, or the engines 206 may include the protocol parsing engine 106, the tagging engine 108, and the content parsing engine 112. In one example, the engines 206 may be implemented as a combination of hardware and firmware. In the examples described herein, such combinations of hardware and firmware may be implemented in several different ways. For example, the engine firmware may be executable processor instructions stored on a non-transitory, machine-readable storage medium, and the engine hardware may include a processing resource (e.g., implemented as a single processor or a combination of multiple processors) to execute those instructions.
[0080] In the present examples, the machine-readable storage medium may store instructions that, when executed by the processing resource, implement the functionality of the engine. In such examples, the computer system 100 may include the machine-readable storage medium storing the instructions and the processing resource for executing the instructions. In other examples of the present subject matter, the machine-readable storage medium may be located in a different location, but accessible to the computer system 100 and the processor 102.
[0081] The computer system 100 may further include the data 208, which serves, among other things, as a repository for storing data that may be retrieved, processed, received, or generated by the protocol analysis engine 106, the tagging engine 108, and the content analysis engine 112. The data 208 may include the protocol analysis data 210, the tagging data 212, the content analysis data 214, and other data 216. In one example, the data 208 may be stored in the memory 202.
[0082] In an exemplary implementation, the network card 204 may receive the data stream of data packets via the communication network. The network card 204 may separate the data stream into multiple processing RX queues and allocate each processing queue to at least one processing core 104-1, 104-2, 104-3, ..., 104-n. In an example, the network card 204 may separate the data stream into the multiple processing queues based on the RSS (Receive Side Scaling) algorithm. Such an algorithm makes it possible to distribute packets across multiple Psa, Psb queues (receive queues). There are several distribution algorithms, the most used being called "Toeplitz" from Microsoft (registered trademark).
[0083] It should be noted that each of the multiple processing cores 104-1, 104-2, 104-3, ..., 104-n may allow different instances of the multiple engines to be executed thereon. For example, separate instances of the protocol parsing engine 106, the tagging engine 108, and the content parsing engine 112 may be executed in parallel on each of the processing cores 104-1, 104-2, 104-3, ..., 104-n. However, for ease of understanding, the following implementation example has been explained with respect to a single processing core 104-1 of the processor 102, hereinafter referred to as the processing core 104.
[0084] In reference to the Figure 5 , an example of packet reception and distribution is shown.
[0085] The network card 204 receives the packets according to step S200.
[0086] According to step S202 the network card directly sends the packets to the cache memory 202.
[0087] According to step S204, the network card sends the packet fields to multiple RX queues and chooses the correct queue according to the RSS (receive side scaling) algorithm scaled on the receiving side.
[0088] According to step S206, each CPU core is bound to an RX queue.
[0089] According to step S208, each CPU core retrieves a batch LOT of packets from the cache memory (RAM) 202.
[0090] According to step S210, the packet Pn is received by a CPU core, the first protocol in the protocol chain (or stack) is analyzed according to the DAP analysis (S212) according to the invention.
[0091] In one example, the BDDS session dynamic packet database may be stored in the protocol analysis data 210. In another example, the BDDS database may be included in the data packet knowledge database 110.
[0092] In this example, in addition to the dynamic session database BDDS, the data packet knowledge database 110 may also include a static data packet database. The static data packet database may include markers based on empirical knowledge of protocol characteristics, and wherein the empirical knowledge includes algorithmic means for detecting protocols based on standards on location, logical links between communication protocols, requests for RFC comments, and frequency patterns of the communication protocols.
[0093] The protocol analysis engine 106 can also store the communication protocol thus identified in the labeling data 212. The labeling engine 108 can then access the labeling data 212 and associate a label on the data packets thus analyzed and whose protocols are thus identified.
[0094] The tagging engine 108 then transmits the tagged data packets to the content analysis engine 112. The content analysis engine 112 analyzes and extracts the data packets based on the tag associated with them. For example, the content analysis engine 112 may analyze and extract a first data packet with a tag indicating a first communication protocol based on the first communication protocol. Similarly, the content analysis engine 112 may analyze and extract a second data packet with the tag indicating a second communication protocol differently than the first data packet. The content analysis engine 112 may then store the analyzed and extracted data packets in the content analysis data 214.
[0095] In one example, the content analysis engine 112 may analyze and extract the data packets (or metadata from said packets) to monitor and visualize data traffic, detect a reduction in quality of service, detect cyberattacks, and identify any inconsistencies in the network configuration. If the content analysis engine 112 detects any of the aforementioned events based on the data analysis and extraction, the content analysis engine 112 may generate a trigger indicating the occurrence of the event upon analyzing the data and extracting a set of data packets from the data stream. In such a situation, the set of data packets may be stored for further processing. In one example, the set of data packets may be stored in the other data 216.
[0096] There Figure 3illustrates the computer system 100, in accordance with another exemplary implementation of the present invention. As already described, the computer system 100 may include the processor 102 having a plurality of processing cores 104-1, 104-2, 104-3, ..., 104-n. The computer system 100 may further include the network card 204 coupled to the processor 102 and the multiple processing cores 104-1, 104-2, 104-3, ..., 104-n included therein. Further, each of the multiple processing cores 104-1, 104-2, 104-3, ..., 104-n may be capable of running separate instances of the protocol analysis engine 106, the tagging engine 108, and the content analysis engine 112. Further, the computing system 100 may be coupled to the packet knowledge database 110.
[0097] The content analysis engine 112, running on the processing core 104-1, can then analyze and extract the first data packet based on the data tag associated with it.
[0098] In one example, the protocol analysis engine 106 and the content analysis engine 112 may sequentially perform DAP protocol analysis as illustrated in figures 6 And 7 , followed by analyzing and extracting DAC data for the data stream received via the communications network. For example, once the protocol analysis engine 106 has identified the communications protocol for the first data packet, the first data packet may be labeled and forwarded to the content analysis engine 112 for analyzing and extracting data.
[0099] Alternatively, while the content analysis engine 112 performs the analysis and data extraction on the first data packet Pn, the protocol analysis engine 106 may simultaneously begin performing the DAP analysis for a second data packet Pn+1 following the first data packet in the data stream Pn.
[0100] In practice, the execution of DAP analysis can be followed sequentially by DAC data analysis and extraction for data packets on a single CPU processing core.
[0101] Alternatively, DAP analysis and DAC extraction of data following DAP analysis can be processed in parallel on one or more cores or dedicated machines, which facilitates scalability to handle a higher flow of data received from the communication network. Thus, the techniques described above can facilitate the processing of data streams having data traffic exceeding 100 Gbps.
[0102] In another example, as shown in Figure 4, one instance of the protocol analysis engine 106 as well as several instances of the content analysis engine 112 may be executed on the processing core 104-1. That is, once the protocol analysis engine 106 has performed the DAP analysis on the data packets of the data stream and identified the communication protocol for the data packets, the processing core 104-1 may allow the parallel execution of several instances of the content analysis engine 112 to process data packets based on different labels associated with the data packets, the different labels being associated according to the communication protocol identified for the data packets of the data stream.
[0103] In practice, a single processor core consecutively processes DAP protocol analysis followed by DAC content analysis and extraction.
[0104] For scalability purposes, it is possible to dedicate cores, complete processors or dedicated machines whose objective is to run several DACs, in the case where the analysis and extraction of metadata are too heavy to be done on a single processor core.
[0105] In this manner, multiple data packets having different associated labels can be processed in parallel by the processing core 104-1, thereby increasing the overall throughput of data packets analyzed and extracted by the computing system 100 in a given time period.
[0106] Alternatively, designing a solution based on asynchronous, two-step processing of packets (DAP on the one hand and DAC on the other) allows for a physical break, by separating DAP processing from DAC processing (here, DAC processing is after DAP processing for the same data packet). Based on user requirements, the resources allocated to DACs may become congested. This break then allows dedicating certain cores to a single DAC job. Beyond the cores of a single CPU processor, it is then possible to dedicate entire processors to the DAC, or even entire machines.
[0107] In reference to the figures 6 to 18 , the invention also relates to a method for analyzing a data flow of data packets received via a communication network, the data flow comprising batches of packets each defined by a chain of communication protocols attached to at least one session.
[0108] The method according to the invention comprises an analysis of DAP protocols according to a first step of analysis of the first protocol Pi of a chain of communication protocols according to a step of classification by explicit detection S10 configured to verify whether the first protocol Pi announces the following communication protocol Pi+1 of the chain of protocols.
[0109] In practice, in the event of an announcement, the following protocol Pi+1 thus announced is identified, while in the event of no announcement, the method according to the invention is configured to analyze the following protocol Pi+1 according to a classification step by session detection S20.
[0110] The session detection classification step S20 according to the invention is configured to verify whether the protocol Pi+1 is attached to a known protocol chain according to a dynamic decision tree by querying a dynamic session database BDDS comprising identified protocol chains.
[0111] According to one embodiment of the invention, after identification of a protocol during the session detection classification step S20, the dynamic session database BDDS is updated.
[0112] In case of attachment, protocol Pi+1 is identified, and protocol Pi+2 is analyzed by repeating the steps of classification by explicit detection S10, classification by session detection S20.
[0113] Alternatively, in case of no attachment, the Pi+1 protocol is analyzed according to a deep packet inspection classification step S40.
[0114] The deep packet inspection classification step S40 is configured to identify the communication protocol of the packet Pi+1 according to a dynamic decision tree correlated to a knowledge database BDC comprising protocol analysis parameters and a base of markers specific to each known protocol.
[0115] In practice, if specific markers of a tested protocol are detected, the Pi+1 protocol is then identified.
[0116] According to one embodiment of the invention, after identification of a protocol during the deep packet inspection classification step S40, the dynamic session database BDDS is updated.
[0117] Alternatively, in the event of failure to identify the protocol Pi+1, the method according to the invention comprises a sub-step of transmitting a list of candidates of potential protocols for Pi+1, to be taken into account according to at least two detection branches B1, B2, each detection being attached to a determined sub-session to analyze the following protocol(s) Pi+n with n>_2 by repeating the steps of classification by explicit detection S10, classification by session detection S20, and classification by deep packet inspection S40 until at least one protocol whose identity is certain is identified.
[0118] In other words, a detection branch B1, B2 will be generated based on a hypothesis of a given potential protocol, and the identification of protocol Pi+n after Pi+1 will be implemented by repeating the classification steps S10, S20 and S40.
[0119] If a Pi+n protocol with certain identity is identified on a detection branch B1, B2, the detection branch B1, B2 will be retroactively validated, and the remaining unvalidated detection branches will be discarded.
[0120] According to one embodiment of the invention, after identification of a protocol during the steps of classification by session detection S20 and classification by deep packet inspection S40, or by a posteriori identification, the dynamic session database BDDS is updated.
[0121] In the case where the identification of a Pi+n protocol whose identity is certain is not possible on a detection branch, the Pi+1 protocol is then classified as unknown S60 retroactively.
[0122] Advantageously, updating the dynamic session database BDDS allows for an acceleration of the identification process, and to limit the protocols labeled as unknown.
[0123] The method further comprises a labeling step comprising associating a label with the data packets based on each session for which the protocols have been identified.
[0124] The method according to the invention further comprises, after each classification step S10, S20, S40, a step of calculating a session digital fingerprint Hi+n from a chosen hash function, said digital fingerprint Hi+n being calculated on the basis of the first identified protocol, and on the previously calculated digital fingerprint Hi+n-1 of the already identified protocol chain without taking into account the attached content.
[0125] In practice, each digital fingerprint Hi+n is calculated on the basis of dynamic parameters or tuples chosen and specific to each type of protocol, each type of protocol having its own number of defined markers also called n-Tuples.
[0126] For example, the defined markers also called n-Tuples can be, but not limited to, the group formed by Destination IP, Source IP, Destination Port, Source Port, Protocol, IP address, Port, QoS quality of service parameters, Network Tag, Session volume, Packet size, Retry count, Version, Type and version of the encryption algorithm, Encryption type, CERT (Computer Emergency Response Team) of the certificate, SNI (Server Name Indication) value, Packet size, Returned IP, Error flag, Domain name, Client version, Server version, Encryption algorithm version, Compression algorithm, Timestamp, IP version, Hostname, Lease-time, URL, User agent, Number of bytes of attached content, Content type, Status code, Cookie header, Client name,request service, error code value, request type, protocol value, response timestamp, privilege level, keyboard type and language, product identification, screen size, or any other similar specific metadata extracted from the protocols in one or more data packets of the validated session, similar specific metadata extracted from the content attached to one or more data packets of the validated session,
[0127] As an example in accordance with the invention, each protocol can with a specific set of n-tuples: Table of sample extractable metadata for a list of selected protocols. PROTOCOLS EXAMPLES OF EXTRACTED METADATA VLAN and VxLAN Network tag MPLS Id TCP Session volume, packet size, number of retries TLS version, type and version of the encryption algorithm, CERT of the certificate, value of the SNI DNS Packet size, returned IP, error flag, domain name, rcode SSH Client version, server version, encryption algorithm version, compression algorithm DHCP Timestamp, IP version, Server IP addresses, Endpoint IP address, Originating port / protocol - TCP or UDP - Server or Endpoint hostname, Lease-time,... HTTP Url, user-agent, number of payload bytes, content-type, status code, cookie header, ... Kerberos client name, service requested, error code value, request type, protocol value, response timestamp, privilege level, encryption type, ... LDAP session duration, number of logon errors, end of session flag, query result code, error code, ... RDP cookie username, keyboard type and language, client version, product ID, screen size, ...
[0128] The step of calculating the digital fingerprint Hi+n is followed by a step of recording said session digital fingerprint Hi+n calculated after each protocol identification step following step S40 or after the retroactive validation step S60.
[0129] The recording is done in a hash table integrated into the dynamic session database BDDS, each digital fingerprint Hi+n being linked to at least one chosen session.
[0130] In practice, the digital fingerprints Hi+n calculated after each classification step of each protocol by deep packet inspection S40 being able to be updated retroactively in the event of delayed identification of a protocol according to the verification step S60.
[0131] In other words, the hash table is updated if the detection of at least one protocol of a session requires the implementation of delayed detection on several S60 packets.
[0132] According to one embodiment of the invention, in the event of detection of tunneled, multiplexed, multichannel protocols in a certain manner, the method according to the invention comprises a first sub-step of generating at least one detection branch A1, A2, B1, B2, C1, C2 per verified protocol to be taken into account for the subsequent analysis.
[0133] According to a second sub-step, each detection branch A1, A2, B1, B2, C1, C2 will be treated as a unique protocol chain capable of being analyzed, and comprises a sub-step of calculating a unique digital session fingerprint Hi+n from a chosen hash function, attached to a sub-session determined for each detection branch A1, A2, B1, B2, C1, C2, and making it possible to analyze the following protocol(s) Pi+n.
[0134] Finally, the detection of tunneled, multiplexed, or multichannel protocols comprises a final sub-step of recording the digital session fingerprint Hi+n of each detection branch A1, A2, B1, B2, C1, C2, attached to a protocol chain, the recording step being configured to assign a unique identifier to each detection branch A1, A2, B1, B2, C1, C2 of the tunneled, multiplexed, or multichannel protocol(s) detected, and thus advantageously not to confuse two sub-sessions which could lead to erroneous analysis information.
[0135] In reference to the figures 9 , And 10 is shown, by way of example, an implementation of the method according to the invention according to a linear analysis in accordance with the invention.
[0136] Here, LOT1 includes four individual packets PO, P1, P2, and P3. The PO packet supports the ETHERNET ETH protocol. The P1 packet supports the INTERNET IP protocol. The P2 packet supports the TCP protocol, and the P3 packet supports the HTTP protocol.
[0137] After receiving the LOT1 batch of packets, the P0 packet is read (step SDL1), here P0 = ETH. In step SLD2, the analysis engine checks whether the P0 packet announces the protocol of the next packet P1. Here, we know that ETH always announces the protocol that follows. Here P1 = IP.
[0138] In step SDL3, the engine checks whether packet P1 advertises the protocol of the next packet P2. Here we know that IP advertises TCP.
[0139] In step SDL4, the engine checks whether TCP announces the protocol of the next packet P3. The answer is negative, but protocol knowledge indicates that if TCP port = 80 then it is most likely that P3 = http. If the http test in P3 is true or not, then the session is known or unknown.
[0140] In step SLD5, if the session is unknown (for example P3 is not http) then a digital fingerprint of the IPs of source A, recipient B, ports A and B and a protocol identifier is created. Then the session thus recognized for the first time is stored in the dynamic session database for later analysis.
[0141] In reference to the Figure 11an example of analysis applied to a linear protocol detection has been shown for which the UDP protocol is identified, but does not announce the following protocol, the analysis engine 106 implementing an analysis according to a classification by session detection S20 and by deep inspection S40, the identified port of which is port: 53, and for which one of the most probable protocols is the DNS protocol.
[0142] The DNS protocol is identified as the most likely, and will therefore be tested by attempting to identify markers specific to the DNS protocol.
[0143] Depending on the implementation, not all markers (or labels) for the DNS protocol are found.
[0144] According to the Figure 11 , the QUIC protocol is identified using its own markers by the analysis engine 106.
[0145] In practice, the identification of probable protocols and their testing in case of identification failure are repeated until a limit on the number of chosen tests is reached.
[0146] In reference to the Figure 14 , we have represented a second example of analysis applied to a linear protocol detection with a posteriori identification for which the MPLS protocol is identified on a protocol chain, but does not announce the following protocol,
[0147] S40 deep inspection classification analysis cannot identify the associated protocol if the protocol does not include sufficient markers to be identified.
[0148] In reference to the figures 12 , And 13 an implementation of the method according to the invention is shown, by way of example, for an analysis applied to a detection of tunneling protocols, requiring delayed detection in accordance with the invention.
[0149] Here, LOT2 includes four individual packets PO, P1, P2, and P3. The PO packet supports the ETHERNET ETH protocol. The P1 packet supports the MPLS protocol. The P2 packet supports the ETH CW protocol, and the P3 packet supports the IP protocol.
[0150] After receiving the batch LOT2 of packets (step SPT1), the packet P0 is read (step SPT2), here P0 = ETH. In step SPT3, the analysis engine 106 checks whether the packet P0 announces the protocol of the next packet P1 according to the explicit classification step S10. Here, we know that ETH always announces the protocol that follows. Here P1 = MPLS.
[0151] At step SPT4, the engine checks whether packet P1 advertises the protocol of the next packet P2. Here we know that MPLS does not necessarily advertise the protocol of the next packet.
[0152] The protocol analysis according to the invention implements an analysis according to a classification by session detection S20 and by deep packet inspection S40, for which the most probable protocols are tested.
[0153] We then assume that P2 is followed by an ETH CW control word.
[0154] The method according to the invention will further comprise a step of assuming the most probable remaining protocol, and will continue the detection on the following protocol by testing the protocol(s) normally following the first assumed protocol.
[0155] At step SPT5, if P2 = ETW CW then it is likely that P3 = ETH, classification steps S20 and S40 will then be repeated to check if ETH is correctly identified and validated.
[0156] At step SPT6, if P3 = ETH then P3 announces P4 which is here IP.
[0157] At step SPT7, P4 is confirmed by the probe as IP.
[0158] At step SPT8, the protocol chain is validated, P2 is retroactively validated as ETH CW.
[0159] In practice, the identification of probable protocols and their testing in case of identification failure is repeated until a limit on the number of chosen tests is reached.
[0160] Advantageously, the detection method according to the invention, comprising management of a dynamic hash table on a basis of n-tuples, associated with protocol identification according to explicit classifications S10, by session detection S20, by deep packet inspection S40, and by a posteriori detection, makes it possible to significantly limit the loss of visibility and eliminate cascading errors during the analysis of a very high-speed data flow, unlike the systems of the prior art and in particular those based on a 5-tuple type digital fingerprint calculation.
[0161] The Applicant also observed that prior art systems often require hardware techniques (FPGA or ASIC) that allow Packet Slicing (slicing the packet on lower or higher layers) to accelerate packet processing, whereas the solution according to the invention is a method that does not require hardware techniques to be implemented and maintains a stable packet processing speed for rates greater than 100 Gb / s as a non-limiting example.
[0162] Although examples have been described in language specific to the methods and / or structural features, it should be understood that the present invention is not limited to the specific methods or features described. Rather, the specific methods and features are disclosed and explained as examples of the present invention.
Claims
1. A method for analysing a data stream of batches of packets received via a communications network, wherein the data stream comprises batches of packets each defined by a chain of communication protocols attached to at least one session, characterised in that the method comprises a protocol analysis (DAP) according to the following steps: - -analysing the first protocol (Pi) of a chain of communication protocols according to an explicit detection classification step (S10) configured to check whether the first protocol (Pi) announces the next communication protocol (Pi+1) of the protocol chain: - -in the case of announcement, the next protocol (Pi+1) thus announced is identified; - -In case of non announcement, analysing the next protocol (Pi+1) according to a session detection classification step (S20); wherein the session detection classification step (S20), configured to check whether the protocol (Pi+1) is attached to a known protocol chain according to a dynamic decision-making tree by querying a dynamic session database (BDDS) comprising identified protocol chains: - -in the case of attachment, the protocol Pi+1 is identified, and the protocol Pi+2 is analysed by repeating the explicit detection classification step (S10) and session detection classification step (S20); - -whereas in the case of non attachment, analyses the protocol Pi+1 according to a deep packet inspection classification step (S40), wherein the deep packet inspection classification step (S40) is configured to identify the packet communication protocol Pi+1 according to a dynamic decision-making tree correlated to a knowledge database (BDC) comprising protocol analysis parameters and a database of markers specific to each known protocol; - - if the protocol Pi+1 is not identified, issuing a list of potential candidate protocols to be taken into account according to at least two detection branches, each detection being attached to a determined sub-session in order to analyse the next protocol or protocols Pi+n with n≥2 by repeating the steps of explicit detection classification (S10), session detection classification (S20), and deep packet inspection classification (S40) until at least one protocol, the identity of which is certain, is identified; - -if a protocol Pi+n, the identity of which is certain, is identified on a detection branch, retrospectively validating (S60) the detection branch, and discarding the remaining non-validated detection branches; - -in the case of failure to identify a protocol Pi+n, the identity of which is certain, on a detection branch, retrospectively classifying the protocol Pi+1 as unknown (S60); and - -associating a label with the data packets according to each session for which the protocols have been identified.
2. The method for analysing a data stream of data packets received via a communications network according to claim 1, characterised in that after each classification step (S10, S20, S40): - calculating a digital session fingerprint (Hi+n) from a chosen hash function, said digital fingerprint (Hi+n) being calculated on the basis of the first protocol identified, and on the previously calculated digital fingerprint (Hi+n-1) of the protocol chain already identified without taking into account the attached content, wherein each digital fingerprint (Hi+n) is calculated on the basis of chosen parameters (or tuple) specific to each type of protocol, each type of protocol having its own number of defined markers (n-Tuples); - saving the digital session fingerprint (Hi+n) calculated after each protocol identification step following step S40 or after the retroactive validation step (S60), in a hash table integrated into the dynamic session database (BDDS), each digital fingerprint (Hi+n) being linked to at least one chosen session, said digital fingerprints (Hi+n) calculated after each deep packet inspection protocol classification step (S40) being capable of being retroactively updated in the event of delayed identification of a protocol according to the checking step (S60).
3. The method for analysing a data stream of data packets received via a communications network according to claim 2, characterised in that when tunnelled, multiplexed or multi-channel protocols are detected with certainty, the method according to the invention comprises the following sub-steps: - -generating at least one detection branch per verified protocol to be taken into account for subsequent detection, - -calculating a digital session fingerprint (Hi+n) from a hash function chosen for each detection branch, wherein each detection branch is attached to a sub-session determined to analyse the next protocol(s) Pi+n; and - -saving the digital session fingerprint (Hi+n) of each detection branch attached to a protocol chain, wherein the saving step is configured to assign a unique identifier to each detection branch of the detected tunnelled, multiplexed or multi-channel protocol(s).
4. The method for analysing a data stream of data packets received via a communications network according to claim 2 or claim 3, characterised in that the hash table is updated if the detection of at least one session protocol requires the implementation of delayed detection on several packets (S60).
5. The method according to any of claims 1 to 4, wherein the knowledge database (BDC) comprises a static knowledge database, wherein the static knowledge database comprises markers based on empirical knowledge of the characteristics of the protocols, and wherein the empirical knowledge comprises algorithmic means of detecting protocols based on location standards, logical links between communication protocols, requests for comments (RFC) and frequency models of communication protocols.
6. The method according to any of claims 1 to 5, also comprising performing a data analysis followed by a data extraction (DAC) for the data packets based on the associated label.
7. The method according to claim 6, wherein the protocol analysis (DAP), and the analysis and extraction of the data (DAC) for a data packet are performed dynamically on a single processing core of a multi-core processor.
8. The method according to claim 6 or 7, wherein the analysis and the extraction of the data (DAC) for the data packet are performed on several processing cores of a multi-core processor.
9. The method according to any of claims 6 to 8, furthermore comprising separating the data stream into a plurality of processing queues wherein the protocol analysis (DAP) followed by the analysis and extraction of the data (DAC) are performed on data packets in each of the processing queues.
10. The method according to claim 9, wherein the separation of the data stream into the plurality of processing queues is based on an RSS scaling algorithm on the receiving side.
11. The method according to any of claims 1 to 10, wherein the protocol analysis (DAP) is performed dynamically on layers 2 to 7 of the (OSI) layer model.
12. An IT system for analysing a data stream of data packets received via a communications network, wherein the data stream comprises batches of packets each defined by a chain of communication protocols attached to at least one session, characterised in that the method comprises a processor comprising at least one processing core for processing a predetermined number of data packets per minute and a protocol analysis engine (106) on the at least one processing core, wherein the protocol analysis engine (106) is configured to perform the following steps: - analysing the first protocol (Pi) of a chain of communication protocols according to an explicit detection classification step (S10) configured to check whether the first protocol (Pi) announces the next communication protocol (Pi+1) of the protocol chain, in the case of announcement, the next protocol (Pi+1) thus announced is identified, whereas in the case of non-announcement, the protocol analysis engine (106) is capable of analysing the protocol (Pi+1) according to a session detection classification step (S20); - analysing according to a session detection classification step (S20), configured to check whether the protocol Pi+1 is attached to a known protocol chain according to a dynamic decision-making tree by querying a dynamic session database (BDDS) comprising identified protocol chains: - -in the case of attachment, the protocol Pi+1 is identified, and the protocol analysis engine (106) is capable of analysing the protocol Pi+2 by repeating the explicit detection classification step (S10) and session detection classification step (S20); - - whereas in the case of non-attachment, the protocol analysis engine (106) is capable of analysing the protocol Pi+1 according to a deep packet inspection classification step (S40); - -analysing the protocol Pi+1 according to a deep packet inspection classification step (S40), configured to identify the packet communication protocol Pi+1 according to a dynamic decision-making tree correlated to a knowledge database (BDC) comprising protocol analysis parameters and a database of markers specific to each known protocol; - - if the protocol Pi+1 is not identified, the protocol analysis engine (106) is capable of issuing a list of potential candidate protocols to be taken into account according to at least two detection branches, each detection being attached to a sub-session determined to analyse the next protocol or protocols Pi+n with n≥ 2 by repeating the steps of explicit detection classification (S10), session detection classification (S20), and deep packet inspection classification (S40) until at least one protocol, the identity of which is certain, is identified; - -if a protocol Pi+n, the identity of which is certain, is identified on a detection branch, the protocol analysis engine (106) is capable of retroactively validating (S60) the detection branch, and discarding the remaining non-validated detection branches; - -in the case of failure to identify a protocol Pi+n, the identity of which is certain, on a detection branch, the protocol analysis engine (106) is capable of retroactively classifying the protocol Pi+1 as unknown (S60); and - -a labelling engine capable of associating a label with the data packets as a function of the protocols thus identified.
13. The IT system according to claim 12, characterised in that the protocol analysis engine (106): - -calculates a digital session fingerprint (Hi+n) from a hash function chosen after each classification step (S10, S20, S40), said digital fingerprint (Hi+n) being calculated on the basis of the first protocol identified, and on the previously calculated digital fingerprint (Hi+n-1) of the protocol chain already identified without taking into account the attached content, wherein each digital fingerprint (Hi+n) is calculated on the basis of chosen parameters (or tuple) specific to each type of protocol, each type of protocol having its own number of defined markers (n-Tuples); - -saves the digital session fingerprint (Hi+n) calculated after each protocol identification step following step S40 or after the retroactive validation step (S60), in a hash table integrated into the dynamic session database (BDDS), each digital fingerprint (Hi+n) being linked to at least one chosen session, said digital fingerprints (Hi+n) calculated after each deep packet inspection protocol classification step (S40) being capable of being retroactively updated in the event of delayed identification of a protocol according to the checking step (S60).
14. The IT system according to claim 12 or 13, characterised in that the protocol analysis engine (106), in the event of detection of tunnelled, multiplexed, multi-channel, or multiplexed multi-channel protocols detected with certainty, - -generates at least one detection branch per verified protocol to be taken into account for subsequent detection, - -calculates a digital session fingerprint (Hi+n) from a hash function chosen for each detection branch, wherein each detection branch is attached to a sub-session determined to analyse the next protocol(s) Pi+n; and - -saves the digital session fingerprint (Hi+n) of each detection branch attached to a protocol chain, wherein the saving is configured to assign a unique identifier to each detection branch of the detected tunnelled, multiplexed, multichannel or multiplexed multi-channel protocol (s) .
15. The IT system according to any of claims 12 to 14, wherein the knowledge database furthermore comprises a static knowledge database, wherein the static knowledge database comprises markers based on empirical knowledge of the characteristics of the protocols, and wherein the empirical knowledge comprises algorithmic means of detecting protocols based on location standards, logical links between communication protocols, requests for comments (RFC) and frequency models of communication protocols.
16. The IT system according to any of claims 12 to 15, comprising, furthermore, a content analysis engine (112) executable on at least one processing core to analyse and extract the data packet based on the associated label.
17. IT system according to claim 16, wherein the protocol analysis engine (106) and the content analysis engine (112) consecutively perform protocol analysis (DAP) followed by data analysis and extraction (DAC) for the data stream of data packets, and wherein the content analysis engine performs, separately, data analysis and extraction (DAC) for differently labelled data packets.
18. IT system according to claim 16 or 17, furthermore comprising a network interface card (NIC) coupled to the processor, wherein the network card separates the data stream of data packets into a plurality of processing queues, and wherein the protocol analysis engine (DAP) and the content analysis engine (112) perform packet analysis (DAP) and packet data extraction (DAC) on each of the plurality of processing queues.
19. IT system according to claim 18, wherein the network card (NIC) separates the data stream of data packets according to the RSS scaling algorithm for the receiving side.