What’s the Future of Application Analysis in Provider Networks?
by Carlos MoralesApplication analysis products are in vogue. The bandwidth that is now available to broadband users has enabled providers to offer converged solutions consisting of voice, data and in some cases video to these same end users. These services provide a much-needed set of revenue streams to providers but they also present them with a lot more challenges. The most notable effect is that this pretty much eliminates the idea that data transport is done on a “best effort” basis. Just try telling a consumer that his 911 calls cannot go through because his neighbor is downloading the latest Shakira tune from a PC in Albuquerque. The result: providers have to be much more cognizant of what is traveling over their network and have to take steps to make sure that these revenue producing services take precedence. That brings us back to application analysis. How can you assign priorities when you don’t know what is going on in the network?
Several techniques can be used to figure this out. Flow based solutions such as Cisco Netflow, Juniper cFlow and Foundry sFlow offer a scalable, low cost approach to gain insight into application use throughout the network based on layer 3 and 4 packet information. With it, you can get a lot of useful data on what the makeup is of congestion in key parts of the network and who the hosts are that are generating a lot of the traffic. This approach provides you with the information necessary to make capacity planning decisions and to detect many forms of network abuse. However, it does not completely address all of the applications that providers really want to analyze and does not answer all the questions that will be asked about these applications. Applications such as peer-to-peer can masquerade using ports commonly used on the Internet like http port 80. Other applications such as VOIP RTP use a range of UDP ports that are negotiated out of band and are difficult to key in on using just the port numbers. These applications require delving into the payload information in layers 5-7 of the packets so most flow based data cannot be used to definitively pinpoint this traffic. Extensible versions of flow have come onto the scene recently in the form of Netflow v9 and IPFIX, which have added the capability of including payload data in the export; sFlow has had this functionality for some time. This bears further attention in the future but there are a few barriers to deployment of this today. The support for these new standards is not universal among vendors or even within vendors, the level of support can vary from platform to platform, and there is some legitimate concern about what the impact will be on performance on routers and in network bandwidth when payload is included in the flow exports.
Span or tap based solutions offer considerably more insight into this type of traffic but also bring along some significant deployment challenges. They have visibility into the layer 5-7 information so that they are more capable of fingerprinting applications based on content. With a span port, you can look into the packet payload and potentially re-assemble application data. This gives the ability to accurately say how much of your port 80 traffic is made up of Kazaa vs. BitTorrent vs. http and it could give you the ability to intercept and record a VOIP call from the wire. The downsides of this method are cost scale and management. To get full network coverage across the edge of the provider network, say just upstream of your dslams, or on an MSO just above the headends, there would be a need to deploy 10s or hundreds of these devices. To avoid the problems presented by asymmetry, you really have to deploy much closer to the edge to be effective. The devices themselves are not cheap either. To achieve layer 5-7 inspection on Gbps + links that are feeding end user segments, the devices need to be equipped with reasonably sized switching backplanes and higher end network processors. Another challenge of this method is the actual management of the devices. When you deploy a number of these across your network, it becomes more critical to have some type of central platform that can be used for correlation, reporting and configuration management.
In-line solutions offer yet another set of options to the user but introduce more challenges. With an in-line solution, mitigation in the form of traffic blocking, rate limiting, traffic shaping and stateful inspection becomes possible. Not only are you able to analyze applications and detect issues on the applications, you are able to do something about it. That is very compelling. However, in-line solutions are the bane of a net ops guy’s existence. It is something new to put in my network that could potentially go down and lead to me being paged at 3 in the morning. Things like full redundancy, 5 9’s reliability, fail open relays, hitless upgrades and other measures become immediate requirements. This will delay the time to market for solutions and will definitely inflate the cost associated with these systems.
The next consideration is feature set. Is it enough just to know how much Napster traffic is parading on port 80 in my network or how many times Jim has called Jane using Vonage? That is certainly interesting data and worth having but as with all data, it tends to open up the door to more questions and requirements. This is particularly true given the investment that is necessary to profile some of these applications across a provider edge. Looking at recent security markets, it is clear that the requirements on products adapt over time from a “tell me what’s going on” to a “do something about it” scenario. You need not look further than the IDS market for an example of this. Intrusion detection emerged commercially en masse in the mid 90’s and most major enterprises deployed them along their perimeters. Over time, these customers realized that just knowing that a worm or a hacker is intruding on the network was not enough; they needed to be able to block them in real time. This spurred on the birth of the IPS, which has dominated the perimeter security space for the last few years. Application reporting is already taking a similar trajectory. Some peer-to-peer reporting solutions available today already include the ability to do rate limiting in real time. VOIP solutions are being developed to detect inappropriate use of VOIP, man in the middle attacks, and VOIP based DDoS. This is just the tip of the iceberg in terms of feature sets that are going to be required. Application analysis solutions need to have a roadmap towards providing more of this functionality while providing for scale and central management requirements.
So all of these options have virtues and challenges, which is the right one? The answer can be found by taking a page out your standard security approach: layer your defenses and adapt them over time. You do not have to choose just one option; you just have to choose your options wisely such that they solve your immediate needs, will ultimately integrate together and will grow with your needs. One could start with a flow-based system that for short money could provide a very decent level of coverage and provide for congestion analysis, capacity planning, acceptable use and quality of service analysis. You can then choose the key locations on your network where to deploy deeper application analysis targeted at the applications that are strategic or potentially more harmful to you. For instance, peer-to-peer traffic on the network is not that big of an issue for a provider unless there is congestion in a portion of the network where applications that are more useful are vying for the same network bandwidth. Initial peer-to-peer analysis appliances using span ports can be deployed in these parts of the network first. VOIP analysis can be performed initially at key provider inter exchange locations and regions of the network where these services are more predominant. As the solutions mature and services continue to grow, the footprint can be gradually expanded until full network coverage is achieved.
The key to making this all work is integration. Whether buying a complete solution from a single vendor or buying from multiple vendors and tying them together using a network management or security event management product, it is crucial to maintain an ability to manage and control the elements in a hierarchical manner. The more fragmented the management and reporting for the system, the bigger the burden that will be put on the operations group that will need to manage it. You can deploy a number of best of breed solutions for specific purposes but if there is no way to ultimately integrate them together or obtain useful correlation, the operations burden could outweigh the benefits of the solution.
