The One-Way Active Measurement Protocol or OWAMP was developed by the IP Performance Metrics Working Group (IPPM) as a part of the Internet Engineering Task Force (IETF). The IPPM Working Group, which I am involved with, develops metrics and processes for measuring IP performance in networks; OWAMP is one of those protocols. Specified in RFC 4656, OWAMP creates a process by which one-way measurements such as latency and packet loss may be made.

In reality, OWAMP is the umbrella specification for two underlying protocols: OWAMP-Control (OWAMP-C) and OWAMP-Test (OWAMP-T). OWAMP-C runs over TCP port 861 and is responsible for the negotiation of the various parameters necessary to successfully complete the measurements.  Additionally, this protocol handles the communication of the measurement results back to the initiating host. The OWAMP-T protocol actually sends the test packets, which are used to calculate the appropriate metrics. This protocol runs over a UDP port to be negotiated within the OWAMP-C session. The IP address of the sender and receiver are negotiated as well, allowing physical separation of the OWAMP-C and OWAMP-T endpoints.

OWAMP is a natively supported protocol within BreakingPoint testing tools and we have put together an OWAMP Application Protocol Brief that further illustrates the finer points of this measurement protocol and the benefits you gain by emulating the protocol during testing.

*This is the second in a series of Application Protocol Briefs, the first brief featured was on Citrix.

Posted by Mike Hamilton (2009/06/30)

0 comments | Tags: owamp // Realistic Application Testing //

It appears that talk about the United State’s plans for beefing up our country’s cyber infrastructure is finally turning into action with new details emerging about government plans to create U.S. Cyber Command. Just this week, Defense Secretary Gates approved the creation of U.S. Cyber Command (or "Cybercom). Jaikumar Vijayan wrote the story for Computerworld and explained:

The proposal to create the new command has been expected for some time and is part of an effort to address growing threats to Defense Department and Pentagon networks from foreign and domestic threats.

Those of you in security research have seen much of this coming. The threats have always been out there, but they are now becoming more sophisticated and more frequent. Security attackers are also becoming more creative. Witness the DDoS attack orchestrated by Iranian protesters via social networks this month.

In the testing world we understand that no matter the initiative or the person heading it up, there are going to be challenges for the government agencies, contractors and research organizations tasked with implementing and ensuring the resiliency of mission-critical networks, as well as the devices and the services they deliver.

"Resiliency" is a word that perfectly describes what people are looking to test when it comes to U.S. cyber infrastructure. Resiliency encapsulates both security and performance of the network and the devices that serve as it's infrastructure. If you want to test the resiliency of a device, you have to do it with real-world network scenarios and network simulations. All of this sounds familar to anyone who has been reading this blog since BreakingPoint excels at testing with realistic app traffic, security strikes, line-rate throughput and more.

This morning we put out news around our capabilities in resiliency testing, "BreakingPoint Provides the Only Realistic Network Simulation for Testing Vulnerability and Resiliency of U.S. Cyber Infrastructure". I wanted to share with you a quote from the news release from Des Wilson, BreakingPoint's CEO, where he defines resiliency testing and its importance:

“Resiliency testing is clearly critical to identifying and eliminating threats to the security and performance of our nation’s cyber infrastructure. And the definition of resiliency testing remains simple; test the network and network devices using blended application traffic mixed with live security strikes at line-rate speeds originating from the same address space. However, until today, the government agencies and organizations tasked to optimize and defend the cyber infrastructure did not have these capabilities. BreakingPoint Elite is the only testing tool architected to simulate the conditions of an actual network, providing the resiliency testing capabilities that help make it the only effective defense against net-centric threats and performance issues.”

How do you define resiliency testing?

Posted by Kyle Flaherty (2009/06/25)

0 comments | Tags: cybersecurity // resiliency testing // BreakingPoint Elite //

Here at BreakingPoint, we write all of our application simulation code in Ruby. Lately, I've been working on adding a slew of new behaviors to our IMAPv4 implementation so users can fine-tune their IMAP Application Simulator and Client Simulator flows. At first, this seemed like it would mean a whole lot of typing to wire up twelve new actions.

Instead of copying and pasting all over the place (and dreading the possibility of fixing the same bug in fifteen zillion places), I needed to come up with a code reuse technique that takes advantage of the existing codebase written using standardized naming conventions. Since I'm swimming in these standard names, I figured there must be a way to use Ruby's dynamic typing and extensible classes to make this easier on myself, both now and in the future.

The first trick is to programmatically figure out which application profile class to use when I'm in a particular protocol. For example, if we're in a function in the "Imap" object, I need to get protocol configuration from the "ImapProfile" singleton object. This is pretty easy with Ruby's introspection and the nifty Kernel.const_get() function.

So, let's say we have a (simplified) ImapProfile class:

class ImapProfile
 def self.config
	{:username => "todb",
	 :password => "Shadowfax" # Unguessable! 
	}
 end
end

In the Imap subclass of Application Manager, I'll want to get a hold of those configuration parameters. I can do so with something like this:

module AppManager
 class Imap

  # Get my class name, strip off the superclass
  def my_protocol
  self.class.name.to_s.split("::").last
  end

  # get_profile_params() takes the string from 
    my_profile_object(),
  # gets the associated constant, and invokes 
    the config() method. def get_profile_params
  Kernel.const_get(my_protocol + "Profile").send :config
   end

   end
end

Now we can call the profile object's "config" method by deriving the class name from our own class's name:

irb(main):001:0> @app = AppManager::Imap.new
=> #
irb(main):002:0> @app.get_profile_params
=> {:username="todb", :password=>"Shadowfax"}

That's pretty neat and all, but the real trick is to figure out how to do the same thing with a method name, since (as you'll see) they bear a resembelence to individual action classes. After a little bit of research, it turns out we can perform something similar with the Kernel.caller() function, and again use some string manipulation to get what we want:

def caller_action_to_constant
	caller[1] =~ /`([^']+?)'/
	$1 =~ /^do_(client|server)_(.*)/
	$2.split("_").map {|s| s.capitalize}.join
end

This function takes the second element of the execution stack, extracts the calling method's name (the first regex), extracts the part we care about (the second regex), then splits on the underscores in order to CamelCase the result. In the end, the string:

"do_client_send_user_name"

becomes 

SendUserName

Why not the first element of the call stack array? Well, I'm wrapping this up in an intermediary function, called the action_executor, which takes this string and performs another const_get to actually use it for something:

def action_executor(args={})
 Kernel.const_get
(my_protocol + caller_action_to_constant + "Cmd").send :data
end

So, from now on, the do_ actions can call the action_executor in order to track down the right classes to get the data from:

def do_client_send_user_name(args={})
	action_executor(args)
end

Pretty neat, if you ask me. A complete code listing should be available here, at Pastie.

In the end, this strikes me as an implementation of the OO Delegation design pattern. However, it includes some extra smarts about where the delegatee is, all based on a common naming convention for classes and methods. While the example code is sparse, in reality, the application actions I'm replacing in IMAP were each around 15 lines, and this technique compresses them down to one. I also get the added bonus of centralizing a common function to one spot, to ease future tweaks to the way application protocols work, or, the laughably remote possibility that there's ever a bug discovered there.

Posted by Tod Beardsley (2009/06/23)

0 comments | Tags: Ruby //

I’m Mike Hamilton, BreakingPoint’s Director of Product Management. My first blog post centers around a familiar topic, the importance of testing with realistic application traffic. BreakingPoint supports more than 75 application protocols, and we constantly add additional protocols to help our customers build better, faster, and more reliable products. Understanding these protocols is important as you look to test more realistically. Today I am introducing a new series of resources, one page documents describing each of the 75+ application protocols we support natively, starting with Citrix. This series of “Application Protocol Briefs” will help you to understand why it is important to test with each of these protocols.

Frequently I am asked about UDP “packet blasting”, IMIX, RFC 2544 and other testing procedures. My answer is always the same; these testing “methodologies” are not realistic. Testing a firewall with 100% stateless UDP traffic is pointless when the actual traffic it will see consists of a wide variety of applications over both UDP and TCP.

Let me make an analogy based on my past experiences rock climbing. Climbing up a rock face I’m attached to a rope to prevent a long fall to my death. The rope has been tested with a 5 lb weight dropped from 10 feet. Pointless! This testing tells me nothing about how my rope is going to behave when all 200 lbs of me fall from 15 feet. Testing under realistic conditions is critical, not only for keeping me safe when I fall, but keeping your network equipment performing at a high and secure level.

Realistic traffic begins at the application layer. Each day at work I’m connecting to a network running HTTP, AIM, Jabber IM, Citrix ICA, Windows Live Messenger, database, FTP, SSH, Telnet, SMB/CIFS, NFS, BitTorrent (don’t tell RIAA!), DNS and more. Some of these run over UDP. Most of them don’t. And the traffic is much more than simply HTTP. I want network devices that have been tested with my particular mix of traffic. Unless you enjoy network downtime, lost productivity and general frustration, you should demand the same.

Once you determine the mix of traffic hitting your device, you also need to make sure it is realistic. The best definition of a realistic protocol I’ve heard came from my CTO Dennis Cox, “A realistic protocol is one that can actually talk to a real server”. This makes perfect sense. If my test harness can actually talk to a RADIUS server, I have a pretty good feeling that my RADIUS traffic is realistic. The interesting aspect of this definition is that it removes capture/replay/recreate from consideration in the realism category.

Another important aspect to realistic traffic is the configurability. If my test harness can talk to a real server but is only able to issue a GET / HTTP 1.1, it simply isn’t realistic. I should be able to request any URI, provide any additional headers, and emulate many different types of browsers (Safari, Chrome, FireFox, IE). This argument excludes the use of capture/replay/recreate for realism purposes as well. Nobody wants to capture traffic requesting hundreds of different URI’s from (at least) four different browsers. The problem grows exponentially. Your test tool should do this for you.

See exactly what I mean in our Citrix Application Protocol Brief and look for a new brief every few days.

Posted by Mike Hamilton (2009/06/18)

0 comments | Tags: Citrix // truth in testing // Realistic Application Testing //

This morning we published our latest methodology for realistic testing of server load balancers. Server load balancers are such an integral piece of networking equipment and the adoption of virtualization and cloud computing, as well as the overall increase of network load, have made them an even hotter topic. As with our firewall testing and IPS testing methodologies, the server load balancer testing methodology demonstrates, in great detail including screenshots, how to configure a load balancer and set up the testing tools.

Some highlights from the methodology:

• Testing the number of TCP connections per second the load balancer is able to handle, providing a baseline test of the device’s performance capabilities.
• Emulating blended Layer 4-7 application traffic in order to validate that the load balancer can handle a true network scenario.
• Determining the overall bandwidth the load balancer can support through testing the number of HTTP/HTTPs connections per second the device can handle.
• Simulating dynamic pages and image files to validate HTTP Caching performance and confirm the load balancer is locally caching needed files.
• Confirming the load balancer can handle malformed packets or errors with the packet through application fuzzing.
• Testing RFCs 793, 1945, 2616, 2818, and 3501.

In the news release that went out today the quote from our CTO and co-founder, Dennis Cox summed it up nicely:

“Server load balancers are so important to today’s network infrastructure, helping to provide improved service uptime, redundancy and better application performance. In order to make this happen, server load balancers must have a high level of awareness of application protocols traversing the network, provide local caching and handle a significant amount of simultaneous TCP connections. Now add onto this the influx of virtualization, and today’s server load balancers have become highly complex content-aware devices that help to optimize your network and the applications it is running. Yet traditional testing methodologies, which only call for testing with HTTP traffic, are still being used."

"Simply testing server load balancers with HTTP is unsuitable and irresponsible. True performance and security testing requires realistic and blended application traffic, appropriate throughput and even anomalies such as application fuzzing. The more realistic testing you do today, the better performing and more secure server load balancer you’ll see tomorrow.”

Go check out the Server Load Balancer testing methodology and let us know what you think.

Posted by Kyle Flaherty (2009/06/16)

0 comments | Tags: IPS testing // server load balancer testing // firewall testing // test methodology //