Deep Packet Inspection: What’s next?
This post is also available in : Spanish
Deep Packet Inspection: is this the Future of Analysers?
Since all technology traffic analysers have evolved, and in order to answer the question of what the next step in this evolution is many experts suggest that the deep packet inspection is the point to which all will evolve.
However, deep packet inspection is not a new concept; ISPs have been using it, not without controversy, for some years. Then why is it referred to as the next step?
To answer this we must understand well what deep packet inspection is, how it differs from traditional package inspection, when it is applied, its pros and cons and evaluate whether the above prediction makes sense.
This is exactly what we propose with this post.
We assume that both the data link layer frames and the upper layer packets are composed of two large parts: the header and the data.
The portion known as the data or body of the packet contains the information that you want to transmit from the source to the destination.
The headers, on the other hand, are a group of bytes that the protocols place in front of the data with all the necessary information to establish the communication. We must clarify that in reality we can also find the so-called ¨trailers¨, which are pieces added after the data.
In this article, for simplicity’s sake, we’ll call all non-data headers and call packages to refer to both frames and packages.
Thus, in the headers, we find the source address of the packet, the destination address, the total length of the packet, codes associated with the control and sequencing of the transmission, as well as those related to error control, and so on.
Headers are usually fixed in size and structure; however, which size and which fields make up the header depends on the protocol in question (Ethernet, IP, TCP, UDP, etc.).
On the other hand, the data portion of the package is usually variable in size and usually contains sensitive information for the user.
Let’s think, for example, of the transmission of an electronic mail; depending on the size of the mail that we want to transmit, we might need for example, four packages, each with 128 bytes of header and 896 bytes of data, forming packages of 1024 bytes.
However, the inspection traditionally carried out by packet analysers is based on the evaluation and study of the headers and considers the data portion untouchable.
However, the deep packet inspection proposes the evaluation of the whole packet, including the part that corresponds to the user’s data.
This is the fundamental difference; however, there are more differences that come from the work schemes and the actions carried out.
On the one hand, traffic analysers try not to affect or minimally affect the traffic being evaluated.
Analysers facilitate both real-time and deferred time analysis, and their objective is for the user to determine situations of error or possible errors and correct them by executing actions on the elements that make up the network, such as switches, routers, applications, and so on.
On the other hand, we have the tools that perform deep inspection of packages whose ultimate goal is to exert an action on the traffic. For this purpose, they are based on the following premises:
- The evaluation of packages shall be carried out when such packages pass through an inspection point.
- Packets should be decoded if necessary and analysed.
- Then, according to criteria that can be predefined and configured, it will be decided what to do with the package. Valid actions include modifying its route, assigning or modifying its priority, assigning a specific amount of bandwidth, quarantining it, or even deleting it.
Application of deep packet inspection
By having clear premises that provide the basis for deep inspection procedures, we can establish the areas that may be sensitive to the use of this technology:
It is easy to understand that a direct application is in network security.
In fact, this type of inspection is applied to detect and execute actions on the presence of malware and in the detection and prevention of intruders.
If the reader is interested in the topic of network security we recommend him to review this post.
Encrypted Traffic Monitoring
Using the topic of Security, we have the applications in the monitoring of encrypted traffic.
Since many of the threats use encrypted traffic as a way to enter networks, deep packet inspection can be related to monitoring encrypted traffic.
This relationship is particularly strong within the framework of the tools that follow the strategy of decrypting traffic, evaluating it and whether it is free from suspicion, re-encrypting it and allowing its transmission over the network, and if there is any suspicion of discarding it or at least quarantining it.
Regarding the monitoring of encrypted traffic, we must mention that there is another strategy that disregards the decryption of packets and opts for the evaluation of the metadata associated with the encrypted traffic, from which it makes inferences about whether the traffic can be malicious or not.
With this strategy of not decrypting, deep packet inspection doesn’t make sense.
Obtaining statistical information
One of the most interesting applications of deep packet inspection is precisely the collection of statistical information on the behaviour of the network or users.
An interesting application, but not without controversy.
There is no doubt that we live in an age characterized by a high sensitivity to the protection of personal data and constant legal judgments for unclear applications in their data mining activities.
In this scenario, the application of DPI in the Internet framework (executed by transport providers or organizations that develop mass consumption applications) is often viewed with suspicion and even fear.
You may find this document interesting in which a few years ago the IPR-based activities of Internet provider companies were evaluated.
In any case, whatever the DPI application, it has always been conditioned by a technical aspect: the amount of IT resources required to support the work in real time to evaluate each package in its entirety and take the necessary actions.
All this without affecting the overall performance of the platform.
In fact, the detractors of the deep inspection of packages, after mentioning the ethical aspects, argue as main against the cost of its application.
This is where the two methodologies for applying IPR technology come into play:
DPI by stream
In this methodology every packet that is captured is analysed and decisions are made packet by packet.
Critics of this methodology argue that with large communications, which require the transmission of many packets per transaction, this methodology can be very costly and even inefficient.
DPI by proxy
In DPI by proxy the basic unit is not the packet but the transaction; therefore, packets are captured and stored until all the packets associated with a transaction are available, and that is when the analysis is performed.
If with the first packages of a transaction it is clear that it is a risky communication or that it fulfils the predefined condition, the analysis will stop and the action, whatever it is, will be applied to the whole group of packages.
Proxy DPI detractors argue that the buffer sizing needed to store packets associated with a particular transaction becomes a point of failure that can greatly affect the performance of applications and therefore the platform.
In any case, the existence of these two methodologies and all the controversy around them shows that performance is a crucial point in the application of IPR and that the configuration of the tools has to be carried out maintaining a positive balance between the benefits obtained and the cost of their application.
Is DPI the future?
As mentioned earlier, deep packet inspection has been used for some time now, particularly in ISPs as part of their traffic management and bandwidth optimization processes.
More recently the use of DPI has moved to the corporate world, especially for applications in the area of security, intrusion detection, etc..
Now, the question that interests us is if the deep packet inspection is the future for traffic analysis tools and even for general-purpose analysis and monitoring tools like Pandora FMS.
We must say that traffic analysis tools and monitoring tools are able to extract an enormous amount of very valuable information, making traditional inspection of packages and using protocols such as SNMP, WMI, and so on.
If you want to have an overview of the potentialities of Pandora FMS in its Enterprise version, then visit the link.
It sounds logical that before thinking about whether or not they should do DPIs, it should be evaluated whether the users of these tools take full advantage of them.
Perhaps in the future they will make efforts to make the tools even more intuitive, considering the integration of different tools or developing consulting plans that result in the definition of optimization processes based on the information extracted.
We do not know what the future will bring, but what is certain is that monitoring and traffic analysis are increasingly essential activities for the optimal functioning of any company.
Finally, we invite you to share your concerns about DPI and leave your comments down below.