Possbilities and Functionality

The purpose of HiPPIE is really simple - provide a system whose sole purpose is to examine packets and provide information on what lies within those packets in the context of what internet protocols they use.  This could be as simple as recognizing that it is an IP packet with a TCP header, or even to the point of recognizing that an HTTP session is flowing within the TCP header.  Or even further still, to recognize that it is an SMTP session operating over that HTTP connect tunnel on a TCP session within IP.  Now, the purpose of HiPPIE is not to determine what to do with data, but only to provide that information.  So, that leaves you with a wealth of possibilities in harnessing that information.  Here are just a few below:

• Passive traffic analyzer - By simply setting up HiPPIE in the kernel of a Linux system and pushing traffic into a single-source bridge interface, and using some BASH scripts that will be available and a few simple PHP web pages, one can use HiPPIE simply as a mechanism to get a visual picture of what their internet traffic looks like by protocol.  There are more possibilities as well to this type of configuration, but the main one is just to be able to passively get a picture of your network's usage.
• Inline Protocol/Packet Filter - By setting up a Linux system with HiPPIE as either a inline bridge or as a routing device and forcing traffic through it, via the usage of integration with Netfilter/IPTables to filter traffic, you can leverage the recognition capabiltiies of HiPPIE to actively drop or even tag/limit certain types of traffic.  Some potential usages of such a design would be to filter certain protocols for policy reasons, to find abnormal usages of protocols (SMTP over non-standard ports indicating likely a Spam-proxy), tagging certain protocols for priority within your network routing, or even using some of the Linux built in mechanisms to do that limiting/shaping within the box itself.  There are numerous possibilities with this configuration as well that shouldn't be limited by the possibilities I have provided here.
• Plug-in to a third party system (More of this capability to come) - Once the user-space hooks of HiPPIE have been completed to provide this functionality, the possibilities of using HiPPIE could truly be nearly endless.  Consider an application such as tcpdump being able to pass the traffic it is analyzing through HiPPIE and allowing you to narrow your searching based on what protocols or protocol encapsulations are being used in the packets.  No longer is one stuck with trying to analyze traffic based simply on ports, but rather has extended their examination capability into recognizing packets based on the protocols in use as well.  There are numerous other possibilities of systems that inspect packets for other reasons that could benefit from protocol identification capabilities, but I won't limit that scope by trying to list them off here.  Use your imagination.

Back to Documentation.