Firewall Testing Methodology & Webinar
Wanted to give folks a quick preview of our upcoming high-performance firewall testing methodology which will be available on December 10th. That day we have put together a panel of network security experts for an interactive webinar on the new rules for testing firewalls. Panelists will include:
- William Graham, Check Point Architectural Engineering Manager
- Dennis Cox, BreakingPoint co-founder and CTO
- HD Moore, BreakingPoint Labs Director
StrikePack Email Alerts Keep You Informed and Help Me Wrap Up a Theme
A bit of a public service announcement today for BreakingPoint users. We started to offer StrikePack alert emails that will notify you when we release a new StrikePack. You can opt-in for these emails by heading to the "Member's Access" page and hitting on "Preferences" and of course you can opt-out at any time. You will typically see about one email a week.
Never one to let an opportunity go, this simple announcement becomes a convenient way for me to wrap up my theme this week and I wish I could say I did it all on purpose. As you know, BreakingPoint is consistently keeping users up to date with the latest application protocols and security vulnerabilities to ensure realistic testing. In just the past month BreakingPoint has released four StrikePack’s that include:
- 57 new Security Strikes, including coverage for October 2008 Microsoft Security Bulletins.
- Strikes for exercising and fuzzing various packets in the Routing Information Protocol most commonly used by 'routed for UNIX'.
- Addition of the Gnutella Peer-to-Peer protocol, used most commonly by the iMesh, Morpheus and Limewire clients.
- Updates to the Stack Scrambler component to switch rates once per second when the Rate Type is set to a non-static value.
- Addition of the Apple Safari and Google Chrome client profiles to the HTTP application protocol.
- ...and more.
Are the Apps you Need for Testing at your Fingertips?
The numbers are impressive when you look at peer-to-peer (P2P) network traffic. Recent reports estimate that more than 100 million files are exchanged each day using P2P networks and global P2P network traffic totals 61% of all upstream network traffic and 22% of downstream bandwidth consumption. Large numbers, but nothing compared to the growth estimates with P2P expected to surpass 100 exabytes per month by 2015.
I wrote the above last week when we announced support for testing network devices with encrypted BitTorrent. BreakingPoint obviously already had coverage for eDonkey, BitTorrent, Gnutella but writing this release and realizing 
these numbers really hit home for me the importance of using actual application traffic when you are testing network equipment. Additionally I was doing research on our next supported application protocol and those numbers, in a relative sense, were even more staggering (hint: instant messaging protocol in a particular geography).
Encrypted BitTorrent adds an important element into the mix, since it has become a possible liability for service providers with many folks trying to avoid QoS policies, not to mention possible issues with file obfuscation, law enforcement avoidance and exploit prevention. Overall the immensity of P2P traffic has a severe affect on network devices, both from a performance and security standpoint, so as much testing you can do with this traffic the better.
However, beyond the particular application, this hits home on my gripe from Monday around the often artificial barriers put up that add complexity into the network equipment testing industry. When you are testing network devices you need to be using the traffic that will ultimately go through this device. Dennis wrote about this in "The World is Lacking Background Traffic". The question you have to ask yourself: do you have those application protocols at your fingertips during testing and if not are they easy to get?
Eliminating Complexity in Testing Tools
A statement I heard on Friday: "Testing is hard, testing equipment should be easy."
My response: "Testing is hard, some tools make it harder and yes, it should be easy."
We've talked here about how to make testing easier, through better network equipment testing tools, but typically we focus on product features, script automation or an intuitive user interface. It goes beyond features however. Often companies introduce new testing products that may have been better served, for users, to be an added feature to the product they have already purchased. I realize that legacy testing vendors are cornered because of their original architecture and I also acknowledge the need for specialized testing products for particular needs, but all too often you are adding testing tools to your process, not to mention additonal costs, simply to get a feature you need.
This is not unique to network equipment testing, in fact it is prevalent in the enterprise software space where adding product feature layers and subsequent liscense fees has become an art form. It is not wonder that the SaaS movement gained so much traction and that people rush over to open source. Many times, particularly at the onset, a vendor can actually use this complexity to generate a great deal of revenue and FUD. The product complexity model works when there are limited players in the market to challenge the norm and before users have grown tired of trying to piece all of these different products together.
Making your testing life easier is not simply about product features, I get that, instead it should stem from the way the product is designed, sold, updated, packaged and how you provide training and support. This ability to minimize complexity and maximize functionality, particularly in this economic environment, will serve companies well in their success. Kevin Costner may have heard "Build it and they will come", had he been a network test engineer his internal dialogue may have muttered "Build it, make it all-in-one and eliminate product redundancy and licensing complexity and they will come".
Network Equipment Testing in APAC
I recently sat down with Leonard Zhang out of our Beijing office, to chat about the network equipment testing market in the Asia Pacific (APAC) region. Wanted to share some of our conversation and see if it resonates with some of the experiences many of you have had in global organizations.
What current trends are you seeing in APAC?
In the past months, we have been interacting with many potential customers throughout the region and observed an increasing trend of interest around application and security testing. It is something good to see. The APAC technical wave mostly follows the U.S. trend, maybe 1-2 years delay. But we see the gap closing, for sure. In my personal opinion, the big picture APAC needs to overcome some cultural issues first in order to take the lead at least in some area.
How is your market different in terms of mindset?
A typical Asian puzzle is the conservative mindset. For example, it happens that when we see some potential customer, the first response might be "we never heard of such a testing tool, so no interest" or "a new tool, we don't believe well in new tools...". Such an enclosed mindset, I guess, is not rare to see in some Asian markets. People usually doubt the new innovations but forgot that every great company/product came with a new hat.
With that in mind, how will BreakingPoint make an impact?
Application and security testing is very complicated, and as I stated above it is seeing very high levels of interest, so I am glad that I joined BreakingPoint who understands the complexity of this market. Application and security testing is constantly changing, so it is always new.
What is your goal in bringing innovative network equipment testing to APAC?
I hope we can speed up the process of the "appreciating new stuff" attitude in APAC through our efforts. Only open minds can lead to a position of pioneers, which Asia is really lacking today. Japan would be a good role model to its neighbors in this area.
BreakingPoint LiveLook: QA for QA
We're back with another BreakingPoint LiveLook on this Friday morning. In today's video, Dennis talks to Chuck Summers about writing QA scripts for our network equipment testing products. The two of them also chat about work commutes and Friday beer, not to mention Chuck's plea at the end.
10G = $9.5B Says Research Firm
According to a new report from Infonetics Research, the market for 10 Gigabit per second (10Gbps) networking equipment will grow to $9.5B in 2008...this is up from $7.3B just last year. That is quite the revenue jump, particularly in today's economy. Sean Michael Kerner at InternetNews.com has the full story which expands into the quest for 100 Gig Ethernet:
The researcher (Infonetics) is forecasting growth for 40G to have a compound annual growth rate of 59 percent from 2007 to 2011. Michael Howard, Infonetics' principal analyst and co-founder, said he expects service providers will take up 40G in the near term even though the faster 100G speed is also on the horizon.
100G is expected by Infonetics to start making inroads in 2009, though broader adoption and revenues are not expected until 2013, according to the study. Howard added that 100G is important as it will likely be in use until at least 2025.
In a conversation about these forecasts I thought our CTO Dennis Cox had an interesting comment:
"I think these predictions are a bit early; 10G in the back room, definitely, but you really need some 10G to the desktop (a minor portion at least) to make that much damage. Obviously, some applications are REALLY pushing bandwidth right now and bonding is getting much more common than even I thought it would become, so perhaps that is driving demand, which always skews analysts (in a good way). The other thing to think about; 10G chipsets are really expensive right now -1G is down to 40 bucks a port (which is really cheap) since 5 years ago it was 200 bucks a port."
Dennis is right, we are seeing 10G network equipment in the back room, and his look at the need up front and the chipset costs gel with many questions I have about these numbers. Since I do not have access to the report I'm not sure if Infonetics takes on the challenge that the delayed 40G/100G standard may pose, or the potential of an even steeper economic downturn. Would love to hear from Infonetics on this topic.
OK, here's your chance, tell me what you think of these predictions around 40G/100G, leave comments below or get involved with the conversation on Twitter.
Penetration Testing IPv6 & Infrastructure 2.0
Perusing the web today and found two interesting articles, both with a forward looking edge; some nice reading for you all on this Monday afternoon. The first comes from BreakingPoint's own HD Moore and it dives into Exploiting Tomorrow's Internet Today: Penetration Testing with IPv6. The paper takes a look at how IPv6-enabled systems "...with link-local and auto-configured addresses can be compromised using existing security tools". My first thought was to question the overall importance, since IPv6 has not been emphatically embraced, at least not compared to the promise. However, HD correctly points:
"Even though most networks are not “IPv6” ready, many of the machines on those networks are. The introduction of a new protocol stack introduces security challenges that are not well-known and often overlooked during security evaluations."
Check out the paper and let us know your thoughts; the end lesson for me: "Be Prepared".
The next article that caught my eye today was "The Next Tech Boom: Infrastucture 2.0" by Gregory Ness. Although I have a pet peeve concerning the moniker "2.0", Mr. Ness hits on some important points around static infrastructure, dynamic infrastructure and the players that sit within these camps. The piece dives into, among other topics, how network management costs will continue to rise and that the static players, particularly within a recession, must add more intelligence and automation to their devices and software. The author put it aptly in a reply to a comment I posted:
"They'll benefit from the spread of TCP/IP but not to the extent they could if they became more strategic to the emerging initiatives."
It would be interesting to add the testing factor into this equation for these industry players and how, with the obvious need to rapidly introduce content-aware network equipment, proper testing is not the only prerequisite. The testing itself must be automated, intelligent, quick, easy and ultimately cost-effective. A lot of criteria for network equipment testing but interestingly all things mentioned in the video from last Friday.
BreakingPoint LiveLook: The Future of Network Equipment Testing
No, no, I didn't sit down with our latest network equipment testing product for an interview, I did a little better than that, chatting with Dennis Cox, the CTO and co-founder of BreakingPoint. Dennis reviews the critical aspects of network equipment testing, why testing can be something to enjoy and bit of the company's history. The interview is a good one for anyone involved in testing network equipment performance and security.
BreakingPoint Elite Launches with 15M TCP Sessions, 20 Gbps of Layer 4-7 Traffic and more
This morning we launched our latest product, BreakingPoint Elite. Wanted to share with you all some information around the launch and let you know that I'm going to try and get up some video from Dennis later today about the new product. In the meantime here are some great links for you to check out BreakingPoint Elite:
This is all exciting stuff for us since BreakingPoint Elite is the first testing solution to generate 15M TCP sessions and 20 Gigabits per second of Layer 4-7 traffic in a 4 rack unit chassis. Stay tuned for some video, check out the links above and here is a quick feature overview of the new BreakingPoint Elite:
- 15 million concurrent TCP sessions
- 1.5 million TCP sessions per second
- 20 Gigabits per second of Layer 4-7 traffic in a 4 rack unit chassis
- 80 Gigabits per second of Layer 2-3 traffic in a 4 rack unit chassis
- Scales easily with multiple BreakingPoint Elite's to generate 200 Gigabits per second of Layer 4-7 traffic and 800 Gigabits of Layer 2-3 traffic while retaining a single interface, test configuration and reporting
- An intuitive management interface, multi-user capabilities, integrated Layer 2-7 reporting and extensive automation
- More than 60 application protocols that can be blended with more than 3,600 security attacks and the ability to integrate proprietary application traffic
- Industry-leading vulnerability coverage including complete Microsoft® Tuesday coverage
Five for Friday: Matt Sarrel & Network Equipment Testing on Wall Street
This week for "Five for Friday" I talked with Matt Sarrel, the Founder and Executive Director of Sarrel Group. Sarrel Group is a New York City based product testing, editorial services and consulting firm. Matt and his staff have worked with an exclusive clientele of small hedge fund and financial management companies for more than 10 years building networks, implementing algorithm based trading systems, and building sophisticated data analysis clusters. As we discussed a month ago Matt's group is using BreakingPoint as part of their testing environment. It seemed to make sense, with all the economic news, that we start off tapping Matt's brain about testing on Wall Street. Enjoy!
1) How sophisticated is network equipment testing for firms on Wall Street?
I can’t speak for the larger firms because most of the work I’ve done on Wall Street has been with smaller hedge funds. I’m sure the larger firms must test network equipment before implementing it, but to tell you the truth, smaller firms take the network for granted. They are very focused on their software and the algorithms that they run and will test those almost infinitely. It surprises me that these firms assume that the network functions properly (the same way most people assume that the there will be a dial tone when they pick up the phone) because minimizing latency is crucial for many of these projects. In my opinion, network equipment and network links should be tested more often. I’ve seen companies spend hundreds of thousands of dollars optimizing code and then turn around and run it over a tediously slow WAN link. Taking the network for granted increases the number of unknowns (not a good thing in finance) and puts many projects in potential jeopardy.
2) How will the latest economic alter testing for these types of companies?
There are two ways to look at this. The first is that companies will simply cut their test budgets. The trouble is that most business people don’t understand that systems should be tested before implementation. That’s just some issue that techies need to deal with and times are tough so let’s cut the budget. What those people don’t realize is that the cost of not testing far exceeds the money saved by not testing. Would you want to invest in a fund that is going to use your money to test their system when it goes live? I didn’t think so.
On the other hand, and this is what I hope happens, is that Wall Street realizes that they no longer have the luxury of testing on a live system. In these troubled times, controlling and limiting risk is essential – both in your systems and in your investments. It would make more sense to me for companies to increase the amount of testing in order to limit the risk of systems failing when they go live. There is enough uncertainty in the market; you don’t need that uncertainty to extend into your systems. Spending the money to test and verify that systems work as needed will reduce risk and allow companies on Wall Street to focus on their financial management, investments, trades, and algorithms rather than being sidetracked by something as simple as an overloaded network.
3) No matter the organization, when you are running tests on devices what do you look to do from the start? What is the most important first few steps?
The first few steps occur before the actual testing starts. The most important aspect of any test is understanding how the device will be used in that particular environment and how the device itself works. Without that solid understanding, you’re testing without context, and testing without context is meaningless. It’s like if your son comes home from school and says, “I got a 25 on my test.” What does that mean? A 25 out of 25, a 25 out of 100? What was the average score? What did he get on the last test? Is this in an easy subject or a hard one? Understanding how a device will fit into a particular environment and then testing it congruent to that implementation is what we at Sarrel Group refer to as “real-world testing”. Testing in a void won’t teach you anything about how a device will perform in the real world. Sometimes it takes more time and resources to create an appropriate test bed than it does to run the tests. This is one thing in particular which BreakingPoint greatly simplifies because we can go to a client site and capture real network traffic, then return to the lab and replay it to test network equipment.
4) What are you looking for in your test results? Does this differ from what the vendors are looking to get out of the testing?
As I mentioned in my previous answer, Sarrel Group focuses on real-world testing. My technicians and I have years of consulting experience and have built hundreds if not thousands of networks. We know the issues that customers face when they implement a new technology, and Wall Street firms frequently implement new technology in order to gain a competitive advantage. Most test labs, and I’m being generous here because as far as I can tell it is almost all other test labs, don’t employ technicians with real-world experience. The result is testing under unrealistic conditions which yield results that are inappropriate for most implementations. Interestingly enough, this is almost exactly what most vendors want because almost every device will perform better in a sterile lab environment than in a complex real-world environment. Vendors want test results that max out their equipment and show how fast it is and many times test labs will resort to unrealistic test scenarios to meet these goals.
We see little value in that at Sarrel Group, and I would like to think that the industry has gotten smart enough over the years that corporate buyers see little value in that kind of testing also. For example, I tested an IPSec firewall earlier this year. The company said it could process traffic at wire speed. The sales and marketing materials all said “wire-speed”. When we got it into the lab it was a wholly different story. It could process non-encrypted traffic at wire speed. Turn on IPSec and performance was cut by a third. Then, we advanced from simple Layer 2 bit blasting to run advanced application traffic through the device and performance was cut by another third. So all of a sudden, the 100 Mbps VPN is now a 30 Mbps VPN. You can only get meaningful results by testing under real world conditions.
5) How has testing evolved since you started in the industry?
In the old days, meaning 1990, in order to test we needed to build complex networks with hundreds and sometimes thousands of PCs to generate load. This meant that we need to write all kinds of scripts to coordinate and manage the PC’s and need a few technicians around whose sole purpose was to maintain the testbed. Then automated test tools started to appear and it became possible to simulate an enterprise network environment more easily. But then network equipment and applications got more sophisticated and testing took a lot more knowledge and resources to do properly. I think that this is where most test labs stopped advancing and stayed focused on lower layer simple testing which many of us call bit blasting.
Other test labs, like Sarrel Group, developed methodology to test more complex layer 4-7 devices, but using the old equipment it wasn’t all that easy. One of the reasons why we’ve partnered with BreakingPoint is that these test devices were designed to conduct more complex testing at higher layers and this is the direction the industry is moving in. The days of simple bit blasting are over and the test labs who realize this earlier will be able to test bleeding edge products more quickly and easily than those that don’t.
BreakingPoint LiveLook: Tcl Interface & Corvette interiors
In the latest BreakingPoint LiveLook, Dennis has an interesting conversation with Kris Raney. When you can go from Tcl interfaces to rebuilding a Corvette you might have a shot at being a member of our illustrious media.
The Inevitable Failure of Content-Aware Network Devices
Wanted to point out the new IDC White Paper we posted to the site last week. The report is titled, "IDC Vendor Spotlight: The Inevitable Failure of Content-Aware/DPI Network Devices - and How to Mitigate the Risk." For those of you in the industry, you may recognize the author, Elisabeth Rainge, who also put together IDC's "Worldwide Network Test and Measurement 2008-2012 Forecast."
The report highlights the benefits of testing network equipment using
a broad range of applications and live security strikes at 10 Gigabits
per second speeds with heavy network traffic. Some good data in the report for anyone looking at network equipment testing. Check out the report and let us know what you think.
Network Management Practices
Just finished reading the document Comcast supplied the FCC (PDF) on their network management practices and reading the recaps from CircleID and Wired's Threat Level. This is, as folks point out, more of a historical document since Comcast has already submitted their new practices, but nonetheless it is interesting on a few points. Since we talk constantly about traffic analysis and of course P2P, I've been keeping up with the stories throughout.
What I found the most interesting in light of today's news was not the info around P2P or their new "application-agnostic" practices, it was the fact that Comcast's Jason Livingood who is in their National Engineering & Technical Operations, is commenting on these blog posts and supplying info, links and in some cases taking suggestions. Certainly a thankless job, but he seems to be helping bring a technical voice to the discussion. What have you thought as you've read these stories?
Obviously people will be watching all of this closely and I'm looking forward to hearing your opinions on the new practices they outlined. I'm going to bet some folks have a few things to say about the 250GB cap?
BreakingPoint LiveLook: SSL, Emmy Awards and a Harley
In San Francisco right now attending the Frost & Sullivan Award ceremony tonite and hoping to get some video to you all tomorrow, but I really wanted to post this video that Dennis shot with Mohsin Lari in our QA group. Mohsin and Dennis talk about QA and SSL, but also the fact that Mohsin has an Emmy Award winner in the family and is on a quest for a Harley. Something we all can relate to...well except for winning an Emmy, the award tonite will have to do for now.
Let us know if you have anything that you would like us to video at BreakingPoint or folks you want to see and hear.
Testing Network Devices using Proprietary Applications
As you know, BreakingPoint has a Custom Application Toolkit feature, which allows you to generate stateful application traffic from proprietary apps and then integrate this traffic with BreakingPoint’s testing platform. You can blend the proprietary apps with our standard apps and security strikes or just run them alone, and test their effects on high performance network devices.
Mike Hamilton, our Director of Product Marketing and Tod Beardsley in BreakingPoint Labs got together to demonstrate how to put this feature to good use. The full screencast can be found here (along with our other screencasts), but I thought that this would be of interest to many of you so I've also embedded it below.
DPI Coverage Getting it Wrong
Over the past two days news has trickled out that NebuAd's CEO has resigned and the company is now suspending their web-monitoring plans. Blogs and mainstream media are not only calling this a win for online privacy, but a few have talked about how this will kill off deep packet inspection (DPI) as a technology. ZDnet's "Between the Lines" more specifically wrote:
"...it doesn’t sound like there’s a long prosperous future ahead for deep packet inspection..."
As Dennis commented on the ZDnet post, this is a bit of 'throwing the baby out with the bathwater'. DPI capabilities go way beyond marketing uses, including enhancing network security and data leak prevention. To collectively dismiss DPI because of the NebuAd example is short-sighted and a bit irresponsible.
To elaborate on these points, here are the DPI slides we shared a few weeks ago from Dennis' portion of the DPI webinar. These should be helpful for folks who are only looking at one angle of this story.
BreakingPoint LiveLook: Hitting the Bullseye with UI Design
Dennis had another interesting interview this week, this time with James Magera about designing the user interface for the BreakingPoint testing solutions and his national ranking in Olympic-style archery. Pretty cool stuff; the UI and the archery.
Thanks for all the suggestions on who to film and keep them coming and if you prefer you can ping us on Twitter.
Botnet Simulation
The other day I asked Dennis about botnet simulation and he started to demonstrate it, so we figured we would film a screencast. We ended up reviewing how to simulate a botnet attack using our testing tools. The screencast shows you how to combine application traffic and strike attacks to realistically simulate a botnet attack including the use of strikes such as denial of service and backdoor attacks using IRC. Enjoy:
BreakingPoint Test Methodology for DPI Released
As we discussed last week BreakingPoint has created a detailed test methodology and video series that helps network engineers to test the DPI features of content-aware network devices. Just like we did with the IPS test methodology, you can view the videos and download the full methodology for your own use. DPI is certainly in the news a lot, and much of the coverage focuses on privacy concerns and P2P bandwidth shaping.
Here again is the intro video, than make your way over to our DPI Test Methodology and let us know what you think.
BreakingPoint LiveLook: IETF, Outdated RFCs and Dublin
Yesterday BreakingPoint LiveLook found Mike Hamilton back from his recent trip from Dublin where he took part in the recent IETF meetings. I wish I had gone along for the ride, and not simply to enjoy some pints in the Temple Bar area, but the discussions around outdated RFCs (request for comments). Mike talks in the video about how far behind some of them are when it comes to content-aware and DPI functionality.
Deep Packet Inspection Testing Webinar
As we've been talking about here on the blog and on Twitter, today was the first in a series of webinar's being hosted by NSS Labs on the topic of deep packet inspection (DPI). Dennis Cox, BreakingPoint's CTO, joined the call and had several slides that provided a good overview for what DPI encompasses and the different elements one must recognize when testing for DPI functionality. I thought I would provide the slides Dennis discussed on the webinar and when the archived webinar is available I'll provide you the link.
Deep Packet Inspection is All the Rage
Quick post on some interesting deep packet related information:
- NSS Labs will be kicking off their DPI Webinar Series tomorrow, from what I hear there will be a really good crowd on the line, registration is here. UPDATE: Here's the link to our Deep Packet Inspection Testing slides from the Webinar.
- Miercom announced results of their test of Solera Networks' Deep Packet Capture device. You'll see in the report some of their use of BreakingPoint for network equipment testing. Miercom actually has an easy way to search through their results reports, so take a look.
- Speaking of BreakingPoint and deep packet, very soon we are going to be putting out our latest test methodology, this time looking at deep packet inspection (DPI). Here is an intro video:
BreakingPoint LiveLook: Testing with Real Application Traffic
A little bit of fun on this Friday afternoon...this morning we showed you Todd Manning's look at creating strikes for network equipment testing, well here is Tod Beardsley talking about how he creates the application protocols that folks use in order to properly test network equipment. Tod, after a little prompting, tells us how he creates the protocols and the ActiveX Strike.
BreakingPoint LiveLook: Security Strikes & Patch Tuesday
Our BreakingPoint LiveLook on Monday garnered some interesting thoughts, one left in the comments section asked for a video of the security research team on Patch Tuesday. Instead of waiting till next Tuesday we grabbed the camera and Dennis asked Todd Manning to tell us what it is like on Patch Tuesday and dive into what he does to create the security strikes used in our network equipment testing solution. Enjoy...
Now be sure to vote on Todd's inquiry at the end of the video. Either comment directly on the video (press +) or in the comments section.
BreakingPoint LiveLook: Under the Hood
We continue taking a look at some of the "behind the scenes" activities here at BreakingPoint, for your viewing pleasure. Yesterday we had Dennis show us under the hood of our network equipment testing solution...from processor to packaging. Take a look and if you have any questions let us know, you can comment directly on the video and of course in the blog comment section.
Reminder: What Do You Think
We got a tremendous response to our website survey I posted a few weeks ago. The plan is to close the survey on August 8th, giving you a few more days. Our hope is to get your reactions and thoughts to our website and online community using 9 survey questions. For your trouble you will be entered into a drawing to receive an iPod Touch or one of several $25 gift certificates to Amazon.com.
Thank you to those of you who have already submitted, your input has been extremely helpful.
Testing With Twitter; The Importance of "Real" Applications
We have talked here about the overall importance of testing…particularly the need to test with REAL
application traffic, live security strikes and doing it all at speeds of 10Gps and faster. These days that first criterion, testing with real apps, is getting more and more important. A great example comes from many of the applications popping up, seemingly every day, in the ‘social networking’ and Web 2.0 space.
Twitter is one of those social networking apps that emerged seemingly overnight and rapidly became a social phenomenon. It transcends description but has caught fire and become so mainstream, so fast, it is now regularly mentioned on CNN, USA Today and even CSI (Miami, of course). This exposure, and the applications usefulness, has created enormous growth. Depending on who you talk with there are an estimated 340,000 public Twitter accounts with 60,000 new accounts starting each month, or potentially 2.2M Twitter users (as of July 22nd). Twitter has also seen great usage as a customer service tool, a social network and a lifesaver.
With great success comes great disappointment and scrutiny of course, and Twitter has been getting plenty of poor coverage because of their inability to keep their network functioning at peak performance. It’s a worry of every company, from Fortune 500 to a start-up…if you provide a service that relies on a network, you best know that the components of that network can handle all the application traffic, security strikes and do it with blazing fast speeds. We take this to heart and have actually added Twitter to the real applications folks can now perform protocol testing using BreakingPoint (check out our TweetLease).
Folks like Biz Stone at Twitter and other business heads (I’m talking to you Mr. Zuckerberg) must push their network equipment manufacturers to make sure they are properly testing network devices for today’s sophisticated application usage. Twitter is simply one example of apps that can affect your network performance, but it is something that was not tested on your network devices before they were deployed. Tomorrow there will be more and you need to make sure these are being used to test your equipment.
Of course, this topic brings us into the ‘architecture discussion’ and how it is crucial that your testing tool is being updated with realistic blended apps and security strikes on a regular basis, and by “regular basis” I don’t mean every three months. There is no telling where the next heavy use application traffic will come from but let’s just say my money is on Plurk…just because I love the name.
Latency and the Global Exchange
Earlier this week Cisco put out its study on global exchanges showing that there are at least 50 different cababilities an exchange needs to achieve peak performance. The study focuses on the top ten, which can be seen in the cross-hairs of this graphic. Coming in at number 5 was latency:
Ivy Schmerkmen at Wall Street & Technology has a terrific in-depth look at the study, including this nugget:
Before going through a major upgrade, the London Stock Exchange could handle up to 450 transactions at the peak second. After a four-year IT overhaul project, the LSE's new trading system TradeElect is now able to handle up to 2,500 transactions at the peak second and it cuts the time it took to process an order to 10 milliseconds from 140 milliseconds. Low-latency trading platforms are critical to exchanges that want to go after the algorithmic trading business, according to the study.
This hit home with me since this week I had also been reading a report put out by TABB Group in April, "The Value of a Millisecond" where they estimated, “Up to 10 milliseconds of latency could result in a 10% drop in revenues.” I knew from previous work in the financial services industry that time was money...but wow. It is obvious that exchanges need to have the most up to date network equipment, but in the rush to get these devices deployed, measuring their performance and security is, d'uh, critical (you knew I'd bring it back around to test, right?).
The reason I'm knee deep in all of this research was because this week we announced our support for the FIX/FIXT protocol. FIX (Financial Information eXchange) is the global messaging standard for the electronic communication of "trade-related data" between financial firms such as banks, broker-dealers, exchanges, and industry utilities. If these exchanges need the latest and greatest network equipment, they need that equipment to have been tested using the FIX protocol (and many others, obviously). Just trying to do our part to grab those milliseconds back!
What Do You Think?
It has been a few months since we launched our new website and we wanted to get your reaction and thoughts. We put together a quick survey (9 questions) and we really want to know what you think. For your trouble you will be entered into a drawing to receive an iPod Touch or one of several $25 gift certificates to Amazon.com.
Click Here to take survey
More Intrusion Prevention Discussion
A few weeks ago we talked Intrusion Prevention Systems (IPS) testing and we posted up our videos and methodology. We've gotten some great feedback from the community and will be using some of it in our next set of videos (and we are always looking for more input). With that in the back of my head I was interested to see The Tolly Group's most recent custom test of TrustWave's Intrusion Prevention Appliance. You can download the test summary and look at how they are going to test (full disclosure that they are using BreakingPoint in the testing). We also have more info on security equipment testing.
Filling the Application Gap
Application traffic continues to grow at an astonishing pace, which certainly means many things to many people, but for Network Equipment Manufacturers (NEMs) and service providers it means that network devices must perform with all of this traffic AND do it at high-speeds of 10 gigabit per second and faster. Today we announced a toolkit to allow for native generation of stateful proprietary application traffic (news release). I thought I would also share a couple of graphics we've been working on to show the "application gap" that exists and what we are trying to do about it:
Legacy test vendors have been unable to meet the application traffic needs of NEMs and service providers due to their locked-down architecture. However it is critical to be able to test network equipment with stateful application traffic including business, recreational, malicious, and proprietary application traffic.
As slide 2 shows, BreakingPoint is closing the "application gap" with the release of this toolkit which allows, for the first time, native generation of stateful proprietary application traffic. The equation becomes simple: business, recreational, malicious, and proprietary application traffic plus the ability to simulate this traffic at speeds of 10 Gigabits per second on a single interface and scale up to 160 Gigabits per second and you are talking "real-world performance testing".
Load Profiles for Layer 4-7 Traffic
Dennis just put together a new screencast which gives you a quick tour of load profiles for Layer 4-7 traffic. He also goes into how to create steps and loops in Layer 2/3 test components. For current BreakingPoint users, the load profiles shown in the screencast will be found in the 1.2.1 release.
Below is a preview or you can always view it in full glory in a Separate Window (it's a little over 6 min.).
Deep Packet Inspection (DPI) Webinar
NSS Labs has announced a Webinar series focused on "High-Speed Deep Packet Inspection (DPI)". The Webinar series starts on July 16th at 10am PDT with NSS Labs Chief Scientist, Bob Walder and CEO, Vik Phatak. After the first one we will certainly be discussing in more detail here on the blog and welcome you to ping us on Twitter during the webinar.
More information and registration.
National IPS Testing Week
Looks like this is the week to talk about IPS testing. NSS Labs had some very interesting news and a blog post around their upcoming testing of 10 Gbps IPS devices. BreakingPoint is involved with the NSS Labs test, who released their IPS test methodology in conjunction with the announcement. It is important and interesting to watch other testing methods, particularly from a respected group like NSS Labs. This got me thinking about the one video in our series that I mentioned in my earlier post; "Testing Victims". This video brings home a critical issue around testing content-aware devices when Rik and Dennis discuss how the equipment most likely won't come within 50% of their public performance claims. And the guys note that it's not their fault. It's the legacy testing equipment they used that couldn't truly test the devices with stateful application traffic at the right speeds.
Because I hate to