Another view of application acceleration

In his Face-off column arguing that application acceleration belongs in the network infrastructure, George Kurian of Cisco implies that Cisco’s solution is transparent because it “preserves critical header information and [does] not cause problems for existing services.” This claim is inaccurate. Although Kurian’s premise that transparency is desirable is agreeable in principle, in the real world, header transparency only addresses a subset of issues and a more comprehensive solution is required.

Many applications such as FTP, H.323, VoIP and video are dynamic protocols, and the ephemeral ports are dynamically negotiated and embedded within the data stream. There is no way to know what ports will be used ahead of time. The only way a router can properly identify these dynamic protocols is to snoop control streams for the ephemeral ports.

However, any WAN acceleration product obfuscates the data streams in a proprietary way in order to achieve compression data reduction. As such, it is impossible for a router or intermediary device to discover the ephemeral ports for dynamic protocols. Therefore, application based ACLs in the WAN will be broken even with header transparency. Kurian’s argument is a red herring.

Also, Cisco’s transparent mode implementation, where headers are fully preserved, is not without trade-offs. This approach will confuse IDP/IDS systems and application firewalls. If placed inline, these devices will see a packet header with source: destination information that does not match the expected payload. For instance it may see port 80 traffic, but upon inspection instead of finding HTTP, it will see a proprietary stream of compressed traffic. This may look like a port 80 intrusion. As a result, the IPS/IDS system will generate spurious error messages. To be clear: Cisco does preserve headers and TOS markings if they are already set, which enables an MPLS cloud to honor existing QoS policies. But most WAN acceleration devices now do this. It would be great to see someone set the record straight on this issue, since Cisco has been misinforming the market on this topic for some time.

Craig Stouffer
Vice president, worldwide marketing
Silver Peak Systems
Santa Clara, Calif.

Thoughts on Check Point

Regarding Richard Stiennon’s open letter to Gil Shwed, CEO of Check Point Software: Thanks to Stiennon for saying what so many people who have left Check Point have said for years. It's like working for the world's most highly funded mom-and-pop shop. What Gil says, goes. I was proud of the products, and I still think they have among the best knowledge of security in the world.

You really can't blame Check Point on the failed Sourcefire acquisition. The Department of Defense has always had some unjustified paranoia around Check Point and the Israeli military connection. The acquisition was happening just as the Dubai ports incident happened, and unfortunately, Check Point was between a rock and a hard place. I'll tell you one thing that I was wrong about with Check Point when I worked there, that I now see their logic. It is Check Point's total devotion to the sales channel. Now being a channel partner, and watching other vendors handing me their discards, or even in some cases outright stealing my leads, I really appreciate that Check Point sells only through the channel.

Other vendors, such as Citrix, have deal registration formally in place. Check Point's is informal. They could definitely use a good formal deal registration program.

A regional director once said to me that the key to having a successful region in Check Point is kind of like playing “Hogan's Heroes.” You act like you're doing what senior management wants you to do, then do what needs to be done to get what they want.

Check Point was a company I truly loved to work for, but it's sort of like having an alcoholic in the family. We all can sit around and discuss how great he would be if he just straightened up, but it's really up to him.

Paul Misner
www.smartchive.com

Murky forecast

Regarding “Gartner: IT will waste $100 billion on network overspending”: I agree that savings can be made through the reduction of unneeded features in much of IT, but I have to disagree on the where and how. As an IT administrator for several years with several companies, I have seen the problem from both sides: too much spending where it is not needed and not enough where it is needed. I've seen companies run expensive T-1 lines where a broadband-level connection would be just as good, and companies struggling to use an extensive VoIP system over consumer-level broadband and not understanding why the connection is so horrible. A CEO doesn't have to contend with user complaints of slow systems on a daily basis but does have to worry about the cost of doing business. Part of the issue lies in management’s misconceptions about technology -- most don't understand it so they leave it to the techs because they don't want to be bother with the issues, or they get hooked on buzz words and gadgets they see in magazines and want to use.