The Riverbed Blog (testing)

A blog in search of a tagline

Video – End to End Network and Application Visibility

Posted by bobegilbert on February 24, 2010

Bob Gilbert sits down with Yoav Eilat,
Riverbed's Director of Product Marketing to discuss Cascade, Riverbed's solution
for providing end to end network and application visibility.

9 Responses to “Video – End to End Network and Application Visibility”

  1. I noticed a couple of oddities.
    1) Netflow itself isn’t a standard but rather IPFIX is based on a standard developed by Cisco Systems. Why not mention them or give credit to creating a technology and opening it up as version 9 for IPFIX.
    2) There was no mention how this product integrates with Riverbed’s WAN optimizers. Is that there is no integration
    3) How well does this product work considering Riverbed creates a Tunnel and thus and routers/switches between the Steelhead boxes only see a single source/destination and any netflow/security is not visible due to the tunnel nature.

  2. Yoav Eilat said

    To address some of the questions raised by Vivian:
    1. Cisco is indeed the original developer of NetFlow. Their version is so common that “NetFlow” is often used in the industry as a generic term, but of course the discussion applies equally to all flow versions.
    2. Cascade integrates with Riverbed WAN optimizers in multiple ways. Notably, Cascade has built-in reports to identify optimization candidates and measure the benefits, and Cascade has a branch-office version that can run on directly on the Steelhead appliance.
    3. As a general rule, Riverbed WAN optimization products do not create tunnels. Therefore, Cascade has no problem seeing the traffic.
    Thanks for visiting our blog!

  3. Vivian Chan said

    Might want to read your own blog. The Riverbed box tunnels or as you call it “Proxy”, either way my Firewalls, IPS, QOS and monitoring tools are now useless.

  4. Hi Vivian,
    It sounds like there is a mis-understanding about how our WAN optimization devices work combined with maybe a mis-configuration. We have more than 7,500 customers, many of which that have robust firewall, IPS, and QoS infrastructures. Our devices work very well in those environments.
    The message thread you linked to provides a good description of how our devices work (thanks to Josh Tseng).
    I suggest starting your own discussion thread in the Riverbed community, sharing your concerns, and asking the ~3000 Riverbed customers and Riverbed tech folks in the community if they have suggestions for configuring in your environment.

  5. Josh Tseng said

    Hi Vivian,
    Riverbed Steelhead devices do not do tunneling. Let me say that again…Riverbed Steelhead devices do not do tunneling. It’s quite tiresome when Cisco mischaracterizes our product. But of course, I try to excuse this by thinking of these mischaracterizations as friendly good-natured competition. 🙂
    Once again, Riverbed Steelheads are TCP proxies that work in a similar way to web proxies. I’ve never heard anyone call a web proxy a “tunneling device”, and yet a web proxy has the same effect as Riverbed, which NATs the source and destination IP address. Your firewalls are not useless. We have hundreds of Riverbed customers that are using their Steelheads with firewalls, QoS, and IDS/IPS.
    I think it’s interesting how some people think how tunneling is evil…that is unless it’s Cisco that does the tunneling. WAAS Mobile is a 100% tunneling product, and it has no non-tunneling mode. WAAS appliances also have a tunnel mode. Unlike WAAS, Riverbed does not have a tunnel mode, nor is there any configuration setting or operational mode where the Steelhead does tunneling. We don’t even do IPSec tunneling–we use IPSec transport mode.

  6. Vivian Chan said

    Merely linking to a report that talks about proxy/tunnel.
    @Bob – If you are not knowledgeable to comment directly about the technical items and desire to obfuscate with throwing marketing stuff around, better to just not say anything than appear as a fool. Safe to assume you are either in sales or marketing right and have overstepped your comfort zone.
    @Josh – Again, refering to your own blog.
    Your customer wrote “But of course, the traffic has been transformed by the Steelhead, and any HTTP headers have been hidden by the Steelhead optimization process. This will confuse the security device and possibly cause it to block the traffic.”
    Therefor the FW policies must be changed to allow thus tunnel (or proxy as you call it) and the IPS may block traffic. Web proxies hide the source, just like this product does, as you said Proxy mode.
    Tunneling is evil because it breaks netflow, IPS, and Firewalls.
    Why not answer the question instead of poking at Cisco WAAS mobile? Separate product that runs on an endpoint? Don’t deflect, answer.

  7. Josh Tseng said

    I suggest you give this a rest. A networking proxy is not the same thing as a tunneling device. There are quite a few basic networking references that clearly describe the differences. Here are some references that you can get online:
    Computer networks use a tunneling protocol when one network protocol (the delivery protocol) encapsulates a different payload protocol. By using tunneling one can (for example) carry a payload over an incompatible delivery-network, or provide a secure path through an untrusted network.
    Here is the definition of a proxy:
    An intercepting proxy combines a proxy server with a gateway or router (commonly with NAT capabilities). Connections made by client browsers through the gateway are diverted to the proxy without client-side configuration (or often knowledge). Connections may also be diverted from a SOCKS server or other circuit-level proxies. Intercepting proxies are also commonly referred to as “transparent” proxies, or “forced” proxies, presumably because the existence of the proxy is transparent to the user, or the user is forced to use the proxy regardless of local settings.
    As I explained earlier, the Riverbed fits the latter description (with or without NAT), but not the former. The Steelhead is a transparent TCP proxy. It does not encapsulate the payload protocol into another network protocol. Rather, it terminates the TCP connection and initiates a new proxy TCP connection on behalf of the original connection.
    OTOH, Cisco WAAS has a tunnel mode known as “directed mode.” Cisco WAAS Mobile is a tunneling-based product. If as you say tunneling is evil, then what are you saying about Cisco’s WAAS products???

  8. Vivian Chan said

    You have mentioned Cisco WAAS Mobile again? Why? We are talking about WAN Opt appliances within a network, not a specific user that is remotely connecting from a single PC. Obfuscating things?
    I just read part of your RIOS 6.0 documentation and it states that
    ” Steelhead RiOS Technical Overview
    However, optimized traffic over the WAN flows from a
    appliance to a Steelhead appliance and is meaningful only to those appliances, so Correct Addressing sends that traffic using the appliance addresses. . When performing Correct Addressing, RiOS also utilizes port 7800 for optimized traffic flows by default. ”
    So, meaning to say there is appliance-to-appliance flows which house optimized WAN traffic, thus my firewalls and IPS devices may not see the full picture as well as my netflow/Jflow monitoring tools. Lovely 😦
    So, to the original point of discussion. You wrote that “Rather, it terminates the TCP connection and initiates a new proxy TCP connection on behalf of the original connection.” == The appliance initiates a new connection using on behalf of the original. What are the source and destination? If they are the WAN OPT alliances, then we’ve just dismissed our Firewalls and IPS from duty since the source/destination may be different. Is that right?

  9. Josh Tseng said

    Well Vivian, at least we’re making progress…you’ve stopped saying that Riverbed does tunneling.
    Now, let’s see if WAAS does tunneling. How about we see what Cisco’s own Zach Seils says about this:
    “You can use Directed Mode in WAAS to tunnel the optimized traffic in UDP….”
    Whoops…Zach said the evil word. WAAS does tunneling? And you said that tunneling is evil?
    The ironic thing here is that Cisco’s “directed mode” (yes, the tunneling mode) was introduced because TCP stateful firewalls don’t like how WAAS’s default transparent mode connections manipulate the TCP sequence numbers. Since firewalls will block WAAS “transparent” connections, Cisco had to introduce directed mode. This allows the firewall administrator to open a known port number (4050) to allow WAAS traffic to get through.
    In any case this doesn’t matter because Riverbed offers both transparent mode (just like WAAS) and correct addressing mode. In fact, most TCP stateful firewalls don’t have a problem with Riverbed’s correct addressing connections, as long as they are initiated in the out-bound direction. You also have the option to open the known 7800 port number through the firewall. After all, payload inspection isn’t possible anyway since the data is compressed. Same for IPS/IDS–what are they going to find out from inspecting compressed data? WAAS has the same problem. It’s best to put them on the LAN side.
    Well, I must say this thread has been entertaining, but once again I suggest you give it a rest.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: