Nov 03, 2010

Scrambling the IP Stack for Fun and Profit

by Kirby Kuehl

As Dennis talked about recently, we’ve introduced a lot of improvements and new functionality in firmware version 2.1 for the BreakingPoint Storm Cyber Tomography Machine (CTM)™ (register for a free evaluation). My part of that work centers on the Stack Scrambler component, which allows organizations to determine how networks or devices will handle malformed traffic. Today I thought I would spend a bit of time detailing what is new for Stack Scrambler in 2.1 and how it can help you. And then I’ll be back with another post [Update: you'll find that post via this link] that gives an example of how to use Stack Scrambler.

What Is Stack Scrambler?

Those new to our blog may be wondering what Stack Scrambler does. The Stack Scrambler component validates the ability of a device to handle malformed Ethernet, IPv4, IPv6, TCP, UDP, and ICMP traffic. The reason? Well, we all know that all traffic is NOT perfect, and we see malformed packets all the time. They may simply be due to an application issue, or they could be inserted by evil-doers. Either way, it is important for you to simulate malformed traffic.

Want to go a little deeper? OK! Stack Scrambler randomly corrupts a predefined percentage of various fields within the specified protocol. Throughout a simulation, an uncorrupted ping (ICMP Echo Request) is generated from a source IP Address to a destination IP address that is used for only this purpose. An ICMP Echo Response packet is expected, and if the number of unreceived ICMP Echo Responses is greater than the value defined in the criteria, then the device fails.

The Stack Scrambler Rewrite for v2.1

In previous releases, the Stack Scrambler component has had the ability to validate the integrity of different protocol stacks by sending malformed IPv4 and IPv6, TCP, and UDP packets to a device. The functionality of the earlier versions of Stack Scrambler closely mirrored that of IP Stack Integrity Checker (ISIC).

With the 2.1 release, the Stack Scrambler component has received a complete rewrite, transitioning from Ruby to C. We did this because, during the design phase, it became obvious that the Stack Scrambler component would be sharing much of the same functionality as the Session Sender component, which was already written in C. It made sense, then, to share as much of the backend code as possible, allowing more features to become available for Stack Scrambler, such as Source and Destination Port Distributions, expanded Data Rate options, and expanded Payload options.

ICMP Support Leads To Greater Things

Stack Scrambler has always used the number of dropped diagnostic pings as its measurement criterion, counting the number of sent pings versus the number of received pings. (Diagnostic pings are uncorrupted ICMP Echo Requests and Replies from a unique source and destination address.)

One of the tasks required for porting the Stack Scrambler component was to implement ICMP and ICMPv6 Echo Request and Echo Reply support in the Network Processor. Since both Session Sender and Stack Scrambler now share functionality, Session Sender now has ICMP available as a transport protocol as well.

Now that it was possible to send and receive Diagnostic Pings, it was trivial to then add ICMP and ICMPv6 Type, Code, and Checksum field corruption. The reporting for diagnostic pings has also changed from a bar graph to a more informative line chart that plots sent, received, and dropped pings over time.

Conclusion: Fuzz Thyself

During the development of the new Stack Scrambler component, we often “fuzzed ourselves” at the L2, L3, and L4 layers during validation. Based on what we learned from that experience, we sprinkled new safety and correctness checks throughout the product, not only improving the robustness of Stack Scrambler and Session Sender, but other components as well.

We’re proud of all the work that went into firmware release 2.1, and hope that our users will continue to push us for even better functionality and realism in the future. One thing already on our plate as part of an upcoming release that prompt the industry to rethink LTE testing: full support for SCTP scrambling.

If you have thoughts or questions on Stack Scrambler and how to use it, please leave them in the comments!

Tags: