Home | Services | Events | Features | Interviews | Profiles | Reviews | News | Resources | Press | Archive

The critical need for user defined scripting

by Phillip Pao

An emerging catch phrase in the networking industry is the "application aware network." So what does it mean for a network device to be application aware?

Here's one interpretation. An application aware device is one that is capable of performing selected application specific tasks. To do this, the network must have a certain level of application fluency. Network devices must also be flexible enough to accommodate unique, application specific requirements. A key driver that will enable networks to achieve true application awareness is user defined scripting.

Scripting is the only realistic way to deliver the rich functionality requirements of a truly application aware network. An application aware networking device must provide complete control of when, how and what to do with application traffic at any point in time within an application transaction. Scripting is an ideal way to deliver this functionality in a flexible and granular way. User adoption of application aware scripting is dependent upon a few critical success factors. These factors include:

1. ease of use,
2. maximising functionality, and
3. support from a rich user community

Ease of use

It is certainly true that the most common, simple networking functionality related to various applications, services and protocols can be configured using a GUI or single line CLI. But if deeper application awareness is needed, GUI and CLI methods become cumbersome and complex.

As the number of parameters that need to be changed, the number of events that need to be monitored and the number of parameters adjusted based on the condition of events become numerous, scripting becomes the obvious way to implement the desired behavior. As much of an oxymoron as it sounds, ease-of-use is greatly improved using scripts, when implementing more complex, application aware networks. Flexible, commonly understood scripting syntax is the best way to gain acceptance of scripts in networking solutions. The basic premise of this idea is that if you want the user to easily understand how to write scripts for network gear to make it application fluent, use a language and syntax that application developers are familiar with such as TCL.

Regarding the commands themselves, the script commands need to leverage off-the-shelf commands, if possible, as well as be extensible and fast so that performance and functionality are not impaired. An example of how scripting is typically the easiest way to implement an application aware networking solution is content scrubbing. Let's say a given application transmits payload data such as social security numbers in open text. Rather than re-writing the application and deploying a fix that re-writes the private data on all servers hosting the application, one could implement a resource masking policy that hides the sensitive information, such as a social security number, by replacing that information with a benign substitute or eliminating that information altogether.

Let's assume that in order implement this, you need to:

1. Identify a specific characteristic that indicates the contents of an HTTP request actually contains sensitive information (say, a class of uri's)
2. Don't allow the content of those requests to be chunked, to allow for proper content re-writing on the response from the Web Server
3. Find any instance in the HTTP payload that follows a pattern of 3 numbers, a "-", then 2 numbers, a "-", then 4 more numbers
4. Replace any of the above patterns found in the payload with "xxx-xx-xxxx"

Writing a script, although possibly intimidating to the novice, is the easiest way to implement the solution yet give enough flexibility to accommodate any application specific nuance.

For instance, without scripting, how would one easily and flexibly be able to tell the network device what specific characteristics indicate the HTTP request carries a social security number? What if there were many independent characteristics instead of just a class of URIs? Also, what if the social security number could be with or without the dashes? What if they wanted to mask only the first part of the social security number because the last four digits needed to be preserved by the application on the client side?

Trying to use a GUI that covers all these nuances would be maddening. If such a GUI were designed, it would be so crowded with parameters that the user would see it as way too confusing.

Maximising functionality

This implementation allows users to use many of the standard script commands, plus a robust set of extensions that the vendor provides to further customise scripts to meet specific requirements. The scripts created can be simple or sophisticated, depending on the content-switching needs and can be a combination of vendor specific commands as well as recognisable standard commands. Scripts can work for virtually any IP protocol to address not only HTTP application challenges but also SIP, FIX, DNS, RTSP, XML and others.

Scripts allow enormous flexibility and granularity in functionality. To illustrate this, let's look at performing traffic analysis and generating statistical traffic output. Depending on the purpose, a user could be interested in a number of statistical displays. The user may want statistics of occurrences (e.g. number of connections, etc.) of different traffic types such as:

1. GIF vs HTTP vs FTP vs other traffic types
2. Dynamic vs static traffic
3. Traffic by browser type
4. Traffic by authorisation type
5. Traffic by particular URI address used/accessed
6. SSL vs non-SSL traffic
7. Compressed vs Uncompressed traffic

Furthermore, the user may want to examine traffic by user groups by counting the number of connections made by certain groups of IP addresses, virtual servers, domains, subclasses or other user groups. In addition to counting the number of connections, the user may want to also count the number of requests, responses, rewritten headers, redirected packets, etc. of any user group. There are dozens of different things you can monitor. Additionally, the user may want to count the number of instances the number of concurrent connections pass a particular threshold or count the number of retransmits that occur over a specified period of time or count the number of responses that exceed a particular size.

Again, there are dozens of different things you can monitor. On top of that, the user may want statistic compilations that nest conditional criteria within one another to get more exact statistics. Scripting gives you the power to drill down into the traffic stream to filter out only the traffic of interest and then report on only that traffic. For example:

1. Show the number of connections made by clients in a specific IP range, that carried HTTP traffic, that used Explorer 1.1, and were redirected to backup node(s) during a specified time period
2. Show the number of HTTP requests to a specific Virtual Server from a specific Node Pool, but only for instances when the HTTP traffic had a payload length that was greater than a certain size

These are only a few permutations on how statistical counters may be used. The reporting and diagnostic uses of statistical counters are endless. Designing a GUI to accommodate the potential statistics desired by the user can be quite complex. In order to capture all the top requirements of networking statistics, separate dedicated hardware and software solutions are quite prevalent in the industry. But collecting and analysing statistics on an inline, traffic management device is outside the primary focus of most traffic switching/routing vendors so scripting becomes the only realistic, near-term option to provide users with deep diagnostic statistics from their switching gear. It is important to understand that statistical traffic analysis is only one of many functions users would like to perform on their networking devices. Whole other categories beyond reporting such as implementing granular security policies, fine-tuning application optimisation, performing advanced user authentication, protocol/application specific traffic routing or other content-switching activities are equally as complex.

Because of the diverse types of functionality required by different users, scripting becomes the only reasonable option to meet the diverse sets of user needs.

Support from a rich online user community

A user community is much more than a vendor simply answering questions as a form of online tech support. Many user community members of successful sites are the most advanced architects, administrators, and visionaries in the industry. Successful communities include the usual community tools like forums, blogs and Wikis, but these are simply tools. Communities that thrive provide a virtual place where users are stimulated to share best practices and cool ideas that not only make their lives easier, but make them look like technology rockstars at the same time. Ultimately, what makes a community work is the value that users gain from interacting within the community, yielding something they can not get from vendors directly.

Successful community groups pool the collective minds of individual users to take product capabilities well beyond what the manufacturer could do alone. Communities tie together the worldwide set of diverse user applications that no single vendor can fully assimilate and manage on their own. As scripting becomes more pervasive and complex within network equipment, the need for scripting solutions will grow. New and more diverse ways to apply existing scripting commands will continue to come to light, while vendors will be simultaneously developing more commands for users to leverage using the scripting platform offered on the network device. Vendors will lose track of all the different ways scripts can be applied to their devices and users will turn to each other for help. Certainly, vendors need to do their part to support their scripting commands and educate their user community on how to apply these tools, but the pioneering users will explore new ways to apply vendors' existing toolset in innovative ways that originating vendors never dreamed of.

Looking forward

As these scripts become more pervasive, unique, complex and specialised, vendors won't be able to keep up with all the scripting use cases and virtual user communities will become an increasingly critical part in the development of scripts in application aware networks.

Phillip Pao is Product Manager for F5 Networks. The company is exhibiting at Infosecurity Europe 2007, Europe's number one dedicated Information security event. Now in its 12th year, the show continues to provide an unrivalled education programme, new products & services, over 300 exhibitors and 11,600 visitors from every segment of the industry. Held on the 24 - 26 April 2007 in the Grand Hall, Olympia, this is a must attend event for all professionals involved in Information Security. Find out more and register online at www.infosec.co.uk.

Home | Services | Events | Features | Interviews | Profiles | Reviews | News | Resources | Press | Archive
About ITWales | Privacy Policy
All material on this website ©2002-2008 ITWales