Skip Links

Letters to the editor: "Another view of application acceleration"

By Readers, NetworkWorld.com
November 29, 2006 09:39 AM ET
  • Print

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.

  • Print

Videos

rssRss Feed