From the Floor at RSA 2010: Real-World Mobile Network Traffic Validation

On the show floor at RSA Conference there is a lot happening and overall the show seems much more well attended than last year. This show, as most of you know, is also a harbinger of news releases and product announcements. Crossbeam, providers of scalable software and hardware platforms, distributed a few pieces of news leading up to the show and at the conference itself. I went over to visit the Crossbeam booth (#545) while at RSA so check out a live demonstration of their X-Series security platform using four BreakingPoint Elite chassis. With this impressive demonstration in the background I talked with Crossbeam's Peter Doggart.

Q. First off Peter, can you provide us with an overview of what Crossbeam provides?

Crossbeam’s X-Series security platform lets customers virtualize third-party, best-in-class security applications and scale them to meet the needs of large, high-performance network environments. Today, more than 900 leading enterprises and service providers, including 10 of the top 11 telecom carriers worldwide, rely on Crossbeam as the underlying architecture for the delivery of security services.

Q. Crossbeam is demonstrating something very interesting here at RSA, can you tell us about what is going on and why?

In working with service providers over the past year, and in particular mobile network operators (MNOs), it has become evident that they are under enormous pressure to meet growing network demands while simultaneously delivering “clean” data pipes.

What we are showing at RSA is proof that our X-Series security platform delivers the world’s fastest firewall performance to meet the needs of mobile operators. Using BreakingPoint Elite, we are conducting a to stress-test the X-Series chassis. We are running a best-in-class application on the X-Series, Check Point Security Gateway R70 Firewall, to clean, inspect and secure the traffic.

This demonstration shows how service providers and mobile carriers can easily scale their network security infrastructure to cope with the next generation of mobile technology, 4G/LTE, under real-world conditions.

Q. You mention “real world” a few times in your answer and in the news release that went out. What does that mean to mobile network operators?

There is a growing gap between what vendors state on their data sheets and what we typically see out in the real world in terms of performance. There are two key elements at play in the real world. First, we are seeing more attacks, which place a greater burden on our security systems and, second, we are seeing smaller payload sizes, especially with the growing number of mobile devices. The result is that mobile operators need to buy and manage a lot more equipment than they budgeted for as the real-world demands are far greater than they ever anticipated. This is not only more costly to them, but it is also a lot more complex to manage.

Realistic tests like this one at RSA validate that we deliver the fastest-performing firewall on the market under real-world conditions which means that we can stand behind our performance claims and mobile network operators can be assured that their X-Series security infrastructure delivers the flexibility, superior performance and high availability required to handle the unpredictability of growing data traffic demands.

Q. How can this type of validation, throughout the industry, not just at Crossbeam, help the overall performance of MNOs?

Crossbeam’s policy is to be transparent when it comes to performance claims. We are doing the opposite of what many vendors do by actually creating tests that provide worst case metrics, not the best case. Take the RSA live demonstration. We are using BreakingPoint to generate 96 byte HTTP packets, which in the real mobile world would be the worst case payload size. At Crossbeam, we want to create some real-world industry guidelines that everyone follows so mobile operators, government and enterprise customers understand exactly what they are buying, and can capacity plan correctly.

Q. I noticed four BreakingPoint chassis in the Crossbeam booth generating the traffic for the demonstration. Why does Crossbeam use BreakingPoint for product validation?

First, we use the BreakingPoint Elite chassis because they can accurately simulate the type of traffic we see in the real world and, second, because BreakingPoint is the only vendor that can push the Crossbeam chassis to its current performance limits.

Q. How has using BreakingPoint helped the evolution of Crossbeam products?

Because BreakingPoint equipment pushes our chassis to its absolute limits, Crossbeam is better able to fine-tune its performance to address customer needs with the assurance that the X-Series can handle their network demands. In the latest release of the X-Series operating system, for instance, we boosted the number of concurrent IP connections we can support up to 10 million, and increased the new connection rates per second to 320,000. These numbers are critical to mobile operators who need to support the growing number of smartphones and other devices, which create more traffic than traditional mobile phones and are nearly always connected. Without BreakingPoint, we couldn’t have confidence in our real-world performance metrics.

Setting The Standard

Next week is my favorite week of the year. It's the Sales Operations meetings held at our headquarters in Austin. Each year we bring the sales people and sales engineers together to review the previous year and preview the year moving forward. More importantly I get to show off.

2009, from all facets, was an incredible year here at BreakingPoint. Sales had an amazing year, with huge growth. Our employee base grew by nearly 30%, much of that being our heavy investment in the security group. We put out 3 major releases and 3 minor releases of our firmware for the BreakingPoint Elite. And our application protocol list now tops more than 100 and our strikes are over 4,300.

This news is certainly exciting, but that was last year. And this is a completely new year and we are ramping up in engineering like you could not imagine. The next firmware release will once again improve the performance of everything from our application protocols, security engine and our SSL. And, of course this is all done without having to replace your blades and at no extra cost. Bet your other vendors don't say that every year.

Next month I'll be putting together a screencast showing you all the features in our next release. I'll save all the juicy bits for then, but here is a teaser of what to expect:

• Five new test labs, including huge strides for mobile networks.
• Changes in the way we are using the NetLogic network processor.
• Switch from using our network processor cores to do SSL, to leveraging the encryption engine on the chip itself (the impact this has on our number of handshakes is staggering).

Last year we changed the way people test their network equipment, this year we will set the standard.

Reminds me of when I worked at Cisco many years ago and Kevin Kennedy (Vice President) would show a slide in which Cisco was compared to other similar companies. There must have been 30 companies listed and at the time 3Com was below us, Lucent ahead of us and all the way at the top were companies like HP. At the time HP was 10x the size of Cisco. Today, Cisco is tens of billions of dollars ahead of HP, with a third of the employees. 

Every year that presentation showed Cisco passing yet another company. We have the same chart for our industry and the same goals, and some companies were ahead of us at the beginning of 2009. During 2009 we passed four of them and this year we will pass four more. And one day, like Cisco, we'll be at the top of everyone else's list.

NOTE: Sometimes Cisco didn't pass a company, the company fell. I'm seeing a lot of that lately, maybe I should send some flowers.

Wireless

Wireless

Multimedia Message System (MMS) MM1 Protocol

In the most recent StrikePack we included an AppSim to support the Multimedia Messaging Service (MMS) MM1 protocol.  MM1 is the 3GPP interface between the MMS User Agent, which generally resides on the Mobile Station (MS), and the MMS Center (MMSC), and is used for sending and retrieving Multimedia Messages to and from the MMSC and for managing the subscriber's Multimedia Mailbox (MMBox) on the MMSC.  This is essentially how your cellular phone sends and retrieves picture or video messages.

Having worked for nearly my entire tenure at Sipera Systems with cellular protocols (focused on dual-mode VoIP phones), I was already familiar with the overall architecture but I had not had the opportunity while there to dig into the details of the MMS system.  Overall, the MMS system encapsulates eleven different protocols, aptly named MM1 through MM11.  The AppSim included in the most recent StrikePack implements some basic support for the first one, MM1.

MM1, as mentioned above, handles communication for sending and retrieval of media messages via the MMSC, which houses the user's MMBox.  This communication protocol is request and response based and can be sent over either of two transports, the Wireless Session Protocol (WSP, cellular network) or HTTP (data network).  Our AppSim currently only supports transport over HTTP as this is what is more likely to be found on a data network.  In both cases, MMS Protocol Data Units (PDUs) are transported as a content-type of 'application/vnd.wap.mms-message'.  If the message contains media, it is transported as a content-type of 'application/vnd.wap.multipart.related' and is structured per RFC-2387.

The bit about MM1 that I found rather interesting is that, intended to be used over cellular networks, a fairly diligent effort was made to reduce the size of messages as much as possible even though the protocol was seemingly based on the Internet Message Format (IMF, RFC-2822) which is a generalized text (specifically, 7-bit US-ASCII) data messaging format resembling SMTP messages or HTTP responses with single-line header fields and an optional body, or payload, portion.  The size reduction is accomplished using a portion of the Wireless Application Protocol (WAP) standard called Wireless Session Protocol (WSP).  The WSP protocol provides a utility for encoding well-known IMF headers into much shorter, binary representations usually consisting of a single 8-bit integer value called the 'Type' which represents the header name and a Type-specific value of one or more of six primitive data types of 'bit', 'octet', 'uint8', 'uint16', 'uint32' and 'uintvar' which represent the header's value.

'uintvar' is a variable length unsigned integer, itself with it's OWN special type of encoding which consists of taking your normal integer value of whatever size, splicing it up into groups of 7 bits and putting those into subsequent octets using the eighth and most significant bit of each octet as a 'continue' indicator to the decoder so that while decoding it knows the integer value continues with more data in the next octet.  A pretty slick way to do it, but very much unreadable to a human on the wire and a bit of a pain to implement.  I definitely had to dust off my bitwisdom to tackle that one.

Due to there apparently not being an existing Ruby library for encoding/decoding WSP, I essentially had to code most of this up myself from scratch using the specification and a few example pcaps.  Because each header and it's value has it's own, often unique encoding, even for only the headers that we currently support it was a fairly tedious task and required quite a bit of testing and bug fixing.  Luckily Wireshark does have a dissector for MMS (filter for mmse) and was able to lend a hand parsing the development AppSim's output as I built it.  This code is essentially what translates the header setting values that our users provide to the AppSim into the proper binary-encoded header block of data used in the configured action's associated message on the wire.

The BreakingPoint MMS-MM1 AppSim currently supports four actions equating to two types of MM1 messages; Raw Request, Raw Response, Raw Body Request, and Raw Body Response.  The first two require only that the user upload two files, each containing the message to be sent's raw header data and raw body data.  These are ideal for use in replicating messages from a source pcap or other data capture.  The second two require the user upload a single file, the message to be sent's raw body data and have a number of settings which when configured will generate a properly encoded MM1 header to append the supplied raw body data to.

Look for AppSims for both WSP and the remaining MMS protocols (MM2-MM11) in future StrikePack updates!

Toorcon X Mini Wrap-Up

On the whole, I was very happy to have attended the 10th Toorcon in San Diego, CA. Toorcon is probably my favorite small con. The attendance isn't massive but the people are generally more interested and knowledgeable in hacking and security. Not to mention that downtown San Diego is a blast and the weather is absolutely perfect. These were my highlights:

The Future of Lockpicking, datagram
I was glad to see a talk on lock picking that went beyond the realm of a simple how to or a single type attack.  Datagram didn't spend too long explaining the lockpicking techniques even though he did have some good animated visual aids. Instead, he focused a lot on how a lock vendor would react to new attacks getting media publicity. Just like in the software security world, some vendors wouldn't ever go beyond a PR response. Some vendors would add a metal plate in a certain place, much like a software patch, and others still redesigned the locks entirely. Some very interesting industry parallels.

Owning Telephone Entry Systems, Joshua Brashers
So many apartment complexes, condos, and gated communities have computerized panels that visitors can use to ask permission to gain entry. The talk outlined many different types of attacks against these types of systems. Most of these appear to be serviced by 3rd parties and allow you to remotely dial-in. And of course, default passwords are rarely changed. He showed how he was able to “back door the front gate” by adding a new entry that played a “Rick Roll” instead of calling a resident and later opened the gate. Another and more scary attack he outlined was the ability to proxy normal entry calls to his apartment using a VoIP server to perform the MiTM. This looked like it was a lot of fun.

How To Impress Girls With Browser Memory Protection Bypasses, Alexander Sotirov
This was a great talk. Although Dowd and Sotirov gave this talk at Blackhat almost two months ago. It was still a fun and entertaining talk to sit though. Alex outlined the implementations of the newer Microsoft memory protection schemes like SafeSEH, DEP, and ASLR. Then showed how and why none of them were effective in defending Internet Explorer from attacks and how much that impressed the ladies. The paper is here.