In my last post, I talked about some of limitations of DPI and the kind of tools used to combat it. However, DPI is useful in a couple of other scenarios and in this final post, I’ll cover them also.


Traffic Optimisation


As traffic flows across a network, it needs to be managed as it crosses points of contention. The most common point of (serious) contention are WAN links, but even inter-switch links can be put under pressure. Simple source/destination/port policies are often used to match protocols against prioritisation queues. However, for much the same reasons port matching is not good enough for security (lack of specificity), it’s not really good enough for traffic optimisation.


In an enterprise network, consider a branch office that accesses applications in a server farm at a remote data centre. Creating a class for HTTP alone isn’t much use it’s used by many distinct applications. Creating a class based upon destination subnet alone isn’t going to be much cop either. In a virtualized or VDI environments server IPs are going to change often. IP/Port classes are helpful when you need to pull protocols (such as Citrix or Oracle) to the top of pile, but that isn’t good enough in the context of highly contended or long-haul WAN links.


DPI is used by packet shaping and WAN optimization devices to identify traffic flows to the molecular level; individual user and/or Citrix/Virtual Desktop application. This is necessary for two reasons:


  1. So that the administrator may apply granular policies to individual applications
  2. To identify traffic that may be optimized; either as simple priority access to bandwidth, or something more invasive such as Layer 4-7 protocol optimization. 


In the context of protocol optimisation (read, WAN optimization or acceleration) correctly identifying traffic flows is critical. As an example, many years ago Citrix moved the default port for sessions from TCP 1494 to TCP 2598. Many bandwidth management policies identified Citrix by the TCP port alone. When the port moved, unless the network or Citrix administrator was paying particular attention, latency-sensitive traffic was thrown in with the “best effort” class. Unsurprisingly, this usually resulted in an overwhelmingly negative user experience.


Troubleshooting


Deep packet inspection is incredibly useful when it comes to troubleshooting network behaviour. DPI can be used to identify applications on the network (such as the Citrix example above) but also for identify the behaviour of applications, and is the final tool to identify a “something bad” happening on the network.
Just to recap, here is a summary of the “something bad” that DPI technologies can address:


  1. Firewall PAD: Filtering out a deliberately malformed packet that would crash a web server
  2. Firewall Signature: Identifying an otherwise correctly formatted packet that produces bad behavior on a web server that otherwise would lead to an exploit (such as dropping a root kit onto a vulnerable host)
  3. Firewall SSL Inspection: Looking into an encrypted session for either of the previous two attacks.
  4. Traffic Optimisation: Identifying and the limiting applications that wish to use excessive amounts of bandwidth
  5. Identifying applications that are behaving badly despite being from a security perspective “clean” and correctly optimized.


Making this a bit more real world; consider the following scenario. External users complain that a web application you host is performing very badly. Firewall PAD and signatures shows that the traffic between the client and the web server is clean; and there are no other apparent attacks.  Traffic optimization ensures this critical application has priority access to bandwidth between the Web server and it’s Database server. However, performance still sucks. DPI tools can be used to analyze the flows between the client, web, and database server. With access to the entire application flow, poorly optimized SQL queries may be identified. This cascade effect can only be identified by tools that understand the application flows not from a security or bandwidth perspective, but in it’s native context. In my view, these kinds of tools are the least well-implemented and understood, and their widespread and proper use could massively improve the time-to-resolution on faults, and identify many things that were previously not in use.


Deep Packet Inspection techniques are used in many places on the network to address a variety of challenges; I’ve focused on security but there are many other applications of DPI technology. And hopefully I’ve made clear that the  correct identification of network traffic is critical to the proper operation of networks and application management in general.


This is my last post in Geek Speak, I'd like to thank everyone who's read and commented. I've really enjoyed writing these articles for this community, and the feedback has steered the conversation in a really interesting direction.  I've no doubt that I'll continue lurking here for some time to come!


Peace


Glen Kemp (@ssl_boy)