BreakingPoint Labs Blog

Taking A Look at OWAMP

Mike Hamilton — 2009-06-30T05:00:00Z

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.

Resiliency Testing Critical to U.S. Cyber Infrastructure

Kyle Flaherty — 2009-06-25T00:00:00Z

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?

Constantly Hacking Ruby Constants

Tod Beardsley — 2009-06-23T00:00:00Z

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.

End Pointless Testing; Realistic and Blended App Traffic Is A True Test

Mike Hamilton — 2009-06-18T00:00:00Z

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.

Server Load Balancer Testing Methodology Published

Kyle Flaherty — 2009-06-16T00:00:00Z

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.

6 Surprising Facts about IPv6

Brent Cook — 2009-06-15T00:00:00Z

My name is Brent Cook, and I am a software architect at BreakingPoint. After some goading and prodding, I have decided to finally be social and share in the blog fun. Working lately with our IPv6 support, I have a long list of fun facts to share. As you know, IPv6 is a 128-bit addressing scheme designed to solve the various problems with 32-bit IPv4, or AKA the next 'big thing'. Here are some things you might not know about IPv6:

Fact 1: You can get on the IPv6 internet in 10 minutes for free, even if your ISP doesn't support it.

I'm a bit of a 'method' programmer, hence to understand a protocol I have to see how it works in real life. So, in order to understand it, I was determined to get on the IPv6 internet and 'live' IPv6. There are plenty of free tunnel brokers, which basically act like a secondary ISP for your IPv6 connection.

I went to SixXS first, on recommendation of Wikipedia, and since it also seemed like the most flexible. However, access here requires jumping through a series of hoops intended to test the purity of my soul, worth of character and hipness of LinkedIn profile. It is akin to getting the sysop to grant download rights on an 80's era BBS. While waiting for a third level of approval from SixXS, I skipped over to Tunnel Broker, run by Hurricane Electric, and got online in about 10 minutes. The configuration steps are easy, provided you have a router that supports IP protocol 41, also called 6in4 (your Linksys router probably does not). Tunnel Broker also has a fun leaderboard that tracks how IPv6-ready you are.

A couple of days later, after I became an official IPv6 expert (according to Hurricane Electric at least), I finally got the SixXS approval. SixXS is also nice, as their Anything-in-Anything tunnel works as advertised, even behind the most brain-dead IPv4 NAT router (even your Linksys router). Now, armed with full IPv6 connectivity at both work and home, I was ready to dive into the world of IPv6. The first surprise was the enormity of the allotments.

Fact 2: Individual IPv6 allotments are amazingly huge.

When you get an IPv4 address from your ISP, that's all you get - an address. Maybe if you run a business, you get 3 or 4. With IPv6, your ISP gives you at least 2**64 addresses; that is 18,446,744,073,709,551,616 for those counting. IPv6 simplifies routing by making all sites /48, and all subnets /64. With 128 bit addressing, this means you will practically never run out of addresses in your allocated subnet. Want to give your coffee maker its own global address? Do it man, live the dream! Both of the above IPv6 ISPs will give you multiple /64 or /48 subnets for free. It feels almost wasteful, particularly after you take a look around.

Fact 3: There is not a lot to do on the IPv6 internet

It is true, there is not much out there on the IPv6 internet. It is lacking that 'killer app'. For now, it mainly consists of animated gifs when you hit certain sites such as ipv6.google.com doing a little dance and SixXS 'cool stuff' page, which reminds one of the internet, circa 1995. The coolest app that I use regularly is an IPv6->IPv4 gateway, which is basically required to do 'normal' stuff. This works just like NAT, which kind of removes one of the motivations for IPv6 in the first place; end-to-end connectivity.

Why is there not much to do on the IPv6 internet? Because there are relatively few users, so it is a chicken / egg problem. Google's recent survey on IPv6 users (PDF) breaks it down showing that world wide, IPv6 is enabled on 0.238 percent of their users' systems. The data also shows that these users prefer using IPv6 over IPv4 when it is possible, they must not mind wreaking havoc on their command-line life.

Fact 4: IPv6 wreaks havoc on your command-line life

IPv6 addresses use colons and percent signs. This is not the best choice in a world where free punctuation is a scarce commodity. Command-line utilities that support IPv4 addresses generally require odd hacks to work with IPv6, and there are even some cases where there is no choice but to give up and add an entry to /etc/hosts. Here are a few of the interesting ones:

One common method of escaping IPv6 addresses is to wrap it in square brackets:

2001::1 becomes [2001::1]

However, since square brackets are meaningful in a Posix shell, you have to escape the brackets as well:

scp file.txt 192.168.1.1: becomes scp file.txt \[2001::1\]:

The same thing applies to URLs: http://[2001::1], though browser support is spotty. Konqueror, for instance, will load an IPv6 URL, then immediately strip the brackets, so a subsequent reload will fail.

There is an additional type of address, link-local, where the interface is tacked onto the end with a percent sign: fe80::1%eth0. Generally, these addresses are a lost cause for most programs, and I could not find any way to escape them in a browser either. Additionally, you cannot really specify these addresses in /etc/hosts using Linux, though it works with OS X and they look different depending on your operating system's naming convention for interfaces. My suggestion, avoid link-local if you can.

Curiously, rather than adding IPv6 support to well known commands like ping and traceroute, most OSes add completely separate versions, ping6 and traceroute6. Only BusyBox bucks the trend, where its ping and traceroute work with any kind of address, provided you configured support when you compiled it.

One final amazing bit of IPv6 address hackery is found in Windows UNC path names. Because the colon is not allowed in UNC, Microsoft registered ipv6-literal.net so you could write 2001::1 as 2001--1.ipv6-literal.net, or link-local address fe80::1%4 as fe80--1s4.ipv6-literal.net. This seems very strange at first, but it's really growing on me - I wonder if I could get a glibc patch past Ingo Molnár :).

Fact 5: IPv6 is a moving target, your cheat sheet is wrong

The IPv6 RFCs have described a number of interesting and, in hindsight, bad features. These include site-local addresses, IPv4 to IPv6 compatible addresses and variable length subnets. These are removed in later RFCs, so it is unfortunate that early implementers cannot pull back existing deployments.

One interesting example is variable-length subnets. Subnets in IPv6 are fixed at /64. However, your router probably allows you to configure an interface with a /48 or /96 subnet. At the same time, you might get this in your Linux dmesg output: "IPv6 addrconf: prefix with wrong length 48", and things won't work properly.

Your operating system probably lets you configure non /64 subnets as well, which will be a big surprise when you find out that they are not interoperable with later IPv6 implementations. I recommend that if you read an RFC on an IPv6 feature and the document is more than 2 years old, check if it has not already been deprecated in a later RFC. Also, throw out that cheat sheet you downloaded or books you bought if they are even a year or two old. Speaking of the impact of deprecated features, let's look at the impact on firewall rules.

Fact 6: Your IPv6 firewall rules are probably insufficient

With every deprecated feature or address range comes an extra set of firewall rules that need to block the deprecated address block of shame. Thanks to the deprecated IPv4->IPv6 compatible address block, you also need to block every private IPv4 address in your IPv6 rules as well. This can make securing an IPv6 network a challenge. FreeBSD's default IPv6 firewall rules have to block 17 different address blocks by default, and that probably omits some late additions.

ICMP becomes more important with IPv6, since it is used for the required path-MTU feature. However, many firewalls block ICMP entirely, breaking required functionality.

Additionally, your IPv4 firewall rules may not have usable IPv6 analogs, depending on the operating system. For instance, Linux 2.4 and 2.6 up to 2.6.20 do not have functional support for the ESTABLISHED rule for blocking incoming connections. Many popular SOHO firewalls are based on a Linux 2.4 kernel, which complicates any firmware upgrade path to add IPv6 support.

There are other surprising facts of course, including that in 2008, IPv6 celebrated its 10th anniversary. Yet, until the last year or two it has lied in relative obscurity. Hopefully, this article might inspire you to start exploring IPv6 today.

Bringing Clarity to Application Fuzzing

Kyle Flaherty — 2009-06-11T00:00:00Z

Application fuzzing is a critical element in any test scenario and it is a topic we have brought up here on the blog several times, which has generated great interest throughout the industry. With that in mind, I was excited to read the latest “how-to” guide from BreakingPoint Labs’ Sean Bradly. This in-depth guide details how-to use the application fuzzing and BlockFuzzer functionality within BreakingPoint Elite. As Sean writes in the paper, "...fuzzing has long been a part of any security auditor’s handbook. However, it is also a terrific tool to use during the QA process since application fuzzing, through providing malicious or malformed data packets, can quickly determine performance issues and reveal bugs."

Sean’s tech brief is one of several we are developing that go into more depth around different testing functionality within BreakingPoint Elite. As you remember, Dustin D. Trammell and Todd Manning had a deep dive into simulating Distributed Denial of Service (DDoS) attacks a few weeks back and next week we will be publishing several additional security and application protocol briefs.

Head on over to download Sean’s paper and start fuzzing.

Interviewing the CyberSecurity Czar; What Question Would You Ask?

Kyle Flaherty — 2009-06-08T05:20:00Z

“America’s failure to protect cyberspace is one of the most urgent national security problems facing the new administration.”

--Center for Strategic and International Studies

It's not just U.S. military and DoD networks that are at risk. Every day Federal, State and local government networks are hit with tens of thousands of malicious attacks. The FAA, stock exchanges, even power grids are susceptible to legions of hackers around the world. While readers of this blog already understand the network security dangers that exist, others are just now beginning to understand the risks. Terms like "cyber security", "cyber warfare" and "cyber infrastructure" are terms recognized by millions of Americans with the Obama administration's recent focus on the topic. Over the next few weeks I'm going to be diving deeper into a variety of cyber infrastructure issues, and today we start with the news of last week and what we should start looking for out of the new cyber czar.

President Obama has laid out his administration's plan to shore up U.S. cyber security, including a new appointment to the role of "cyber security czar" (or coordinator), a position formerly part of the Department of Homeland Security. In a 60-page report, titled "Cyberspace Policy Review: Assuring a Trusted and Resilient Information and Communications Infrastructure," (PDF) the administration shared the following urgent priorities:

Increase Federal investment to improve security in information and communications infrastructures
Create a public/private partnership to coordinate responses to cyber attacks
Seek International cooperation to mitigate security risks
Raise the public's awareness about the state of infrastructure security

Overall it is clear that the Obama administration believes by bringing the position closer to the White House and granting more power (and money) to the cyber security topic they can achieve these objectives. Critics believe, however, that the role is not being given enough latitude, funds, power, etc. Others believe that the role should be primarily a private one. But it's just not that simple. Starting with the fact that there are already Government funded cyber security initiatives underway.

The Federal government has consistently been introducing programs for cyber security, perhaps not out of a central department, but it has been rapidly progressing. Recently, the Pentagon ramped up efforts in attracting the newest network security talent with a military funded program tapping students. Called "Cyber Challenge" (sick of the word cyber yet...), it will center around three national competitions for high school and college students. The goal, of course, is to find the best and the brightest students and give them an opportunity to help shore up the U.S. cyber infrastruture, now and in the immediate future. Although I'm sure critics have issues with the military establishment getting involved with schools, let's face the facts that this is a difficult challenge and we must have our nation's brightest working on the problems.

The U.S. Army obviously understands cyber warfare and cadets are already being trained to battle this threat. The New York Times had an interesting look into training exercises for cadets at West Point, who were taking part in cyberwar games as a final exam. Although this training is geared towards using cyber security tactics for a military advantage, whereas the President's report only looked at internal defense, it is important to understand that the wheels are already in motion. And, then there's the private sector where companies are rapidly innovating a new generation of security products and services. Our nation's new cyber czar must head into the position knowing that there are already so many initiatives in motion both in the government and corporate world and effectively bridge those two worlds to protect our increasingly vulnerable yet mission-critical infrastructure.

This will involve taking on a CEO-type role, looking at where activities are already effective, where the holes remain and how to dedicate the necessary resources to plug these holes. And, just like our counter-terrorism initiatives, our cyber security warriors must learn to think like the enemy in order to defend our critical internet infrastructure.

With this in mind, I asked folks on Twitter what one question they would ask an applicant interviewing for the cyber czar role, some of the initial answers are below and this will be the focus of our next post on cyber security. What would be your question?

Use Recreate in Testing; Eliminate the Need for External Tools

Kirby Kuehl — 2009-06-04T13:10:26Z

Introduction

Hello everyone, welcome to my first BreakingPoint blog post. Prior to joining the BreakingPoint team, I spent several years as an Intrusion Prevention/Detection Systems developer. In that position, I spent considerable time decoding various protocols and using tools like Wireshark, Tcpreplay, Tcprewrite, and Netdude to view and manipulate packet captures. I was excited to adopt the BreakingPoint Recreate component and implement new features that allow Recreate to assist software developers, quality assurance engineers, and testers in ways that previously would have required external tools.

Background

The Recreate component allows users to incorporate data originating from their real network into the tests conducted in their test environment. Recreate operates in self-described fashion: it recreates traffic based on the data contained in a capture file from any libpcap-based sniffer, such as wireshark or tcpdump, modifying the traffic attributes as necessary to conform to the test network specifications. Prior to the upcoming release (which will be coming soon), raw playback (discussed below) was not possible; instead, the Recreate component rewrote the data to match the traffic parameters specified for the domain, importing only the raw payload. This method had two modes of operation:

Use capture file settings
Use user-specified settings

Using the first setting, Use capture file settings, Recreate will use the data rate, maximum simultaneous sessions, sessions per second, test duration, inter-packet delays, application payloads, and destination ports from the supplied PCAP file. All other fields/parameters will be taken from the Parameters tab. The source port will be randomized.

Using the second setting, Use User-specified settings, Recreate will only use the application payload and destination ports from the PCAP file. The source ports will be randomized and all other fields/parameters will be taken from the Parameters tab. The interpacket delays will be set to ‘0’.

<
The purpose behind these two settings is to allow you to use the application payload from the PCAP file, but still have some control over how the file is replayed. Use capture file settings essentially lets you replay the PCAP as recorded, whereas Use User-specified settings enables you to control how fast or slow the traffic is replayed while still preserving the original payload.

Importing IPv6 Capture Files

Importing an IPv6 capture file is no different than importing an IPv4 file. All imported capture files must be libpcap-compatible. Once the capture file has been successfully uploaded, it will be listed under the Capture File Name list on the Recreate editor screen and selectable from the Filename drop down menu in the Recreate component’s parameters list.

To import an IPv4 or IPv6 capture file:

1.	Select Managers > Traffic Manager from the Menu bar.

2.	Click the Import Capture button.

A new window will display, which will allow you to upload a PCAP file:

3.	Enter a name in the Capture Name field.

Note:

This will be the name displayed for the PCAP in the Traffic Manager. Note that capture file names can only contain alphanumeric characters, spaces, and dashes.

4.	Click the Browse button.

5.	Navigate to the location of the PCAP file and select the file.

6.	Click the Open button.

7.	Select the Allow Overwrite option if you want to overwrite an existing file with the same name (as defined in the Capture Name field).

8.	Click the Upload button.

After the file has been properly imported, it will become available in the Capture File drop down box:

Importing gzipped Capture Files
Often it is valuable to view the transmitted and/or received packet buffers exported from the ports used in one of our tests. This can be accomplished by exporting the packet buffer as shown in the next screenshot:

This will launch an options window (shown below) allowing the end user to choose which slot(s) to export, select transmitted and/or received packet buffers for export, and configure a BPF filter and snaplen for each selection, respectively. Once the Export button is pressed, a lotXPortX.xxxxxxxxxxxxx.pcap.gz file will be downloaded. For increased test efficiency, this release allows Recreate to re-import the generated SlotXPortX.xxxxxxxxxxxxx.pcap.gz file without first having to decompress it on your external file system:

Raw playback

While Recreate's layer 4 payload modes of operation discussed above are still the default, the upcoming release introduces additional raw playback functionality similar to tcpreplay for layers 2-7. This new mode's performance cannot match the payload-only mode due to disk I/O constraints, and the reporting is limited to interface statistics, but it can replay traffic exactly as captured, which can be very useful when testing layer 2-, layer 3-, and layer 4-related issues such as:

Customer or vendor supplied packet capture files
Layer 2 ARP and RARP
Layer 3 ICMP, IPv4, and IPv6
TCP/UDP headers (traditional mode replayed payloads only)
TCP SYN floods, denial of service attacks, and invalid packets

Raw playback can be enabled by toggling the Replay capture file without modification option from false to true:

BPF Filtering

The raw playback mode also supports BPF filter expressions after importing, but prior to sending, the traffic. This can be useful if you want to isolate traffic by IP address, port, protocol, etc. without permanently modifying the capture file. The tcpdump manpage is an excellent source for BPF filter syntax.

The filter string depicted in the following screenshot will display all TCP traffic to and from TCP port 80 involving host 10.10.10.41. This filter will generate traffic exactly as if the PCAP had originated from executing: tcpdump -r ipv-http.pcap ip host 10.10.10.41 and tcp and port 80:

Capture File Looping
Recreate's new raw playback mode also supports looping the capture file from 1 to 10,000 times.

If we look at the Wireshark summary of a PCAP that we are about to loop:

Set the Number of times to loop capture file to 3 and then Save and Run test:

The Wireshark summary of the capture file exported off of our Slot2Port0 interface shows the proper loop count below:

TCP and UDP Port Rewriting

TCP/UDP port rewriting occurs during packet transmission and does not alter the capture file imported onto the disk. Prior to this release, changing the ports in a capture file required using a tool like tcprewrite or netdude to modify the file prior to importing.

To rewrite a port, navigate to the Recreate Parameters tab and choose Modification Options.Rewrite source and destination ports. The format of this parameter is "originalport:newport":

The original imported capture file containing IPv6 TCP port 80 (HTTP) traffic:

The exported packet buffer from the Slot2Port0 interface after the test was completed showing the IPv6 addresses rewritten to IPv4 addresses and the TCP ports rewritten from 80 to 8080:

Port Independent Protocol Classification

In previous releases, Recreate classified protocols based upon TCP and UDP port only. If SSH, normally bound to port 22, was bound to port 80, Recreate would classify the protocol incorrectly as HTTP. If SSH was bound to port 2222, it would be classified as other. Utilizing regular expressions taken from the l7-filter project and libpcre, the internal protocol classifier can now properly detect many standard protocols (SSH, IRC, HTTP, FTP, etc.) bound to non-standard ports as well as protocols that often do not have a standard port associated with them, such as many popular P2P (Bittorrent, Gnutella, etc.) clients. Recreate currently identifies 38 protocols.

Here is a screenshot of SSH running on TCP port 2222. Wireshark does not contain any protocol classification code and as you can see, Wireshark labels the protocol TCP. With Recreate's new classification feature, the generated reports will correctly identify this as SSH:

Prior to this release, the ssh traffic on TCP 2222 would have been reported as other. As you can see below, the protocol is now properly classified. Expect the protocols that we support to be expanded in future releases:

Conclusion

The inclusion of these new features will allow the tester to spend less time obtaining, compiling, learning, and using third party tools to manipulate and replay packet captures files. We have several new features planned, which will make Recreate even more powerful, that I will write about in a future blog post.

Test the Cloud Before Living In It to Avoid Tech Torture

Pam O'Neal — 2009-06-03T12:19:37Z

We don’t often include CNN.com in our blogroll here on the BreakingPoint Labs blog, but this week the news site is offering up an intriguing video blog of Topher Kohan’s experience of living (working) in the cloud. Topher has set a challenge for himself to conduct his daily tasks using only cloud-based apps while filming a diary of his experiences. According to Topher:

“I will try to do 100 percent of my job online and not use any desktop applications. So when I check my e-mail, schedule a meeting or write a document, I will do all of this online and then save it in online storage. If it works, I will be able to sit at any computer in the world, and as long as it has Internet access and a browser, I can log in to some Web sites and work.”

Cloud cynics will be disappointed to learn that the videos are not exactly living up to his headline: “Tech Torture with Topher". Wish I could say the same for my own cloud application performance experiences. But things are just starting to heat up as already Topher has run into issues with Twitter. What? The Twitter Fail Whale already? To be fair, an outage or capacity overload was not really the nature of Topher’s chief complaint. It was the lack of functionality for dealing with the overwhelming volume of tweets from the 400 plus Twitterers he follows.

Tune in to watch Topher as he moves on to more complex applications like Google Docs. Heads up Google, Amazon, Twitter and other cloud vendors – this is no time for a major outage or performance issue. Hope you’ve done your due diligence in the area of cloud testing. There’s a large audience of cloud enthusiasts as well as skeptics watching (and commenting) to see Topher be tortured by 12 hour application outages prior to a story deadline, performance issues that would try the patience of Mother Teresa, or perhaps a major security breach involving the loss of Topher’s personal credit card information. Alas, I find myself a bit too excited by the prospects. Don’t let me down guys.