Wide-Area Data Services (WDS), aka “WAN Optimization” is becoming the most effective way to improve application performance while reducing network traffic. In scenarios where there is significant network latency that would otherwise render many applications unusable, WDS can deliver almost LAN-like speed. Where bandwidth constraints exist and there is no practical or economical option, WDS can help reduce network traffic, allowing you to postpone or avoid circuit upgrades altogether. The technology provides the ability to centralize applications and servers, furthering the cost savings on hardware, software licensing, maintenance and the operation of a distributed architecture.

Because WDS works at the TCP and application layers, it relies on the data being transferred in the clear without encryption. Some VPN implementations negate the ability to deploy WDS if the encryption occurs prior to the WDS appliance. Client-based WDS has emerged from vendors such as Riverbed and, aside from its primary purpose of providing WDS to mobile users, may allow for more flexibility in deploying WDS in VPN environments.

WDS Background

How exactly you define what constitutes WDS and what vendor products qualify is a bit debatable. Specific vendor implementations vary but overall the general WDS concept is the same. There are at least 10 vendors on the market with appliances that interact with applications, clients and servers to “accelerate” application traffic. Vendors may have their own techniques and associated terms, but generally the appliances do some or all of the following:

• Layer 7 (Application-layer) acceleration
• Layer 4 (TCP) acceleration
• Caching
• HTTP acceleration and pre-fetch
• Data compression
• Quality of service
• Proxy file server
• Proxy domain controller

VPN Implications

Most WDS implementations use external router-like appliances that intercept and manipulate network traffic. The appliances must be able to read the TCP header and, depending on the data to be accelerated, the application protocol. If WDS is performed outside the VPN, then there is no issue. WDS will work fine as shown in Figure 1.

But if WDS is deployed in an environment where there are VPN devices that encapsulate and encrypt the data above the IP layer prior to WDS, WDS will not work. The WDS appliances cannot see the upper layer protocols and application traffic necessary to perform the acceleration. This scenario occurs if the WDS deployment is in the core network or is a feature offered by the service provider, as shown in Figure 2.

This issue is more obvious in a client-based VPN scenario, as shown in Figure 3.

In this scenario, even if the central VPN concentrator decrypts the traffic prior to the WDS appliance, the external WDS appliance at the remote branch office cannot see the protocol and application data necessary to perform the acceleration because the PC’s VPN client has encrypted the traffic.

IPv6 Implications

The issue with WDS in a VPN environment is relevant whether the IP protocol is IPv4 or IPv6, but IPv6 may present additional challenges. Two factors related to IPv6 are relevant to this discussion.

First, one of the major improvements in IPv6 is actually not the protocol itself but simply the IPSec mandate. In order for a vendor to truly comply with IPv6 RFC specifications, its IPv6 implementation must include support for the ESP and AH (IPSec) extension headers. This does not mean that IPSec must be turned on, but it must be included as an option in the protocol stack, as opposed to an additional feature that the network administrator may or may not purchase. This will be a benefit of IPv6 because it will likely encourage and facilitate better data security.

Second, IPv6 was designed to facilitate peer-to-peer networking and to get back to the true end-to-end networking model. The primary motivation of IPv6 was to solve was address depletion issue and its many side effects. The biggest side effect is the proliferation of Network Address Translation (NAT) and the complications it presents to many applications. In IPv6, the virtually infinite number of addresses solves this once and probably for all. With most every end system having a unique IPv6 address, NAT can be removed and true peer-to-peer networking can become a reality.

As IPv6 emerges, these two factors will encourage the deployment of secure (IPSec-based) peer-to-peer VPNs. This will interfere with any WDS implementation that uses external appliances. Client-based WDS may be required to overcome this issue.

Client-based WDS

The main motivation for client-based WDS is to provide the feature to mobile users. Staff can benefit from WDS while on the road and away from their home network and (possibly) an external WDS appliance. But client-based WDS may also solve the VPN dilemma. The WDS client functions in the PC’s protocol stack above the VPN client. This allows WDS to be performed before the data is encrypted and illegible to an external WDS appliance, as shown in Figure 4.

Of course, the WDS hub appliance at the data center must located be after the VPN is terminated and traffic is decrypted.

With WDS clients installed on PCs at both ends along with VPN clients, it would be possible to create true peer-to-peer VPNs with traffic accelerated through WDS, as shown in Figure 5.

Conclusions

The main idea behind client-based WDS is to allow mobile users to reap the benefits of WDS. But an additional feature is the ability to provide WDS in VPN environments where it otherwise would not be possible.

Moving forward, WDS technology will become further entrenched in networks in an effort to enhance application performance while reducing network traffic. Client-based WDS is likely to become part of that strategy, providing WDS in a mobile and VPN environments.