design element
print

The Lippis Report Issue 19: Transmission Security: Navigating Virtual Private Networks (VPNs)

Sep 14, 2003 by Nick Lippis

Enterprises constantly struggle with a number of transmission-oriented issues. IT managers are always working to control the costs of wide area networks amid growing business dependence on the WAN ?¬¢‚Äö?ᬮ‚Äö?Ñ?? a sizeable task even in the face of decreasing access and long-haul bandwidth prices. In addition, enterprises are faced with the challenge of providing connectivity to corporate resources for a growing number of partners, suppliers and remote employees, as well as customers. In many cases, enterprises are looking to leverage the Internet to extend the WAN. Oh, and I almost forgot ?¬¢‚Äö?ᬮ‚Äö?Ñ?? they need to accomplish all this securely.

Virtual Private Networks (VPNs) have been available in various forms for years. While numerous vendors have come and gone with new technologies and architectures during that time, it is only recently (within the past 2-3 years) that enterprises have truly begun to recognize the benefits of VPNs. Initially deployed for LAN extension and remote access, enterprises are now deploying VPN solutions as a primary network infrastructure so that they may leverage the Internet to reduce the cost of transport versus Frame Relay, ATM and leased line services.

In this issue, we define the various VPN technologies and approaches and take a practical approach to exploring which VPN solutions are best suited for various enterprise applications.

VPN Alphabet Soup

There are currently numerous VPN options available to the enterprise, including:
?¬¢‚Äö?ᬮ¬¨¬¢ IPSec VPNs
?¬¢‚Äö?ᬮ¬¨¬¢ CPE-based
?¬¢‚Äö?ᬮ¬¨¬¢ Network-based
?¬¢‚Äö?ᬮ¬¨¬¢ MPLS-based VPNs
?¬¢‚Äö?ᬮ¬¨¬¢ SSL-based VPNs

Depending on the application, any one of the above may be ideal for a given enterprise or, as many are finding, a combination of multiple VPN alternatives is often the best solution.

CPE-based IPSec VPNs

The majority of enterprise VPNs are based on self-managed Customer Premises Equipment (CPE). In this scenario, the enterprise owns, operates and maintains the VPN equipment, using the carrier only for physical connectivity to the IP network, generally the Internet. CPE-based IPSec VPNs are widely viewed to be the most secure VPN strategy, as the IPSec session begins and ends at customer sites, not in the carrier network. A VPN appliance/software is deployed either at the LAN
side of the enterprise access router, or is actually integrated with the access router and/or the corporate firewall. IPSec sessions are initiated at the CPE device, encrypting the entire packet flow until it reaches the destination site, where it is decrypted and forwarded to the protected LAN-side resource. Performance of IPSec CPE´s have improved greatly over the past several years, to the point where latency is low enough that some enterprises are running VoIP traffic across their VPNs.

The CPE approach also provides the most control for the enterprise, as VPN equipment is owned, operated and maintained by the IT staff onsite. The VPN can be used both for site-to-site connectivity as well as for remote access for mobile workers with the addition of client software. Cisco (www.cisco.com), Check Point (www.checkpoint.com) and NetScreen (www.netscreen.com) are the established leaders in the VPN CPE space.

Network-based IPSec VPNs

Network-based IPSec VPNs move the equipment and intelligence of the VPN off the customer premise and into the carrier network The basis of the network-based approach is to free the enterprise customer from the complexity of self-managing the VPN service, as well as reducing the capital and operational expenses associated with premise-based solutions. In this scenario, the enterprise installs an access link (typically Frame Relay or DSL) to the carrier´s local point of presence (POP). At the POP, the access link terminates on an IP Service Switch - a large, dense edge aggregation router that has VPN and firewall capabilities on-board. The IP Service Switch encapsulates the enterprise traffic in an IPSec session and forwards it across the carrier
backbone. At the distant POP serving the intended recipient, another IP Service Switch terminates the IPSec session, decrypts the flow and routes it to the recipient site as clear text.

While several carriers, including AT&T (www.att.com), Qwest (www.qwest.com), Broadwing (www.broadwing.net) and NTT/Verio (www.nttverio.com) have offered network-based VPNs, these services have largely been a bust Enterprises have been reluctant to make the leap of faith and assume that the ?¬¢‚Äö?ᬮ??¨invisible?¬¢‚Äö?ᬮ¬¨?? VPN in the network cloud is secure and reliable. There are also concerns regarding IP Service Switch (IPSS) performance, as they concentrate access termination, aggregation, security (encryption and firewall), subscriber management and routing into a single router-based platform. This also points to the IPSS as a single point of failure. Additionally, many enterprises were hesitant to adopt network-based VPNs due to concerns over longevity of the services and the vendors on which they were based. This has turned out to be a valid concern, as many of these vendors (Spring Tide Networks, Corona Networks, Ennovate, etc.) have either suspended operations, been acquired and sunsetted, or are under extreme financial pressure. Of the barrage of IPSS vendors from years past, it seems that only Juniper/Unisphere (www.juniper.net), Nortel/Shasta (www.nortel.com) and CoSine (www.cosinecom.com) remain active in the space.

MPLS-based VPNs

Several tier one and tier two carriers, including AT&T, BellSouth (www.bellsouth.net) and Broadwing, have begun to offer Multiprotocol Label Switching (MPLS) VPNs. MPLS is a router-based technology that accelerates packet-forwarding by applying ?¬¢‚Äö?ᬮ??¨labels?¬¢‚Äö?ᬮ¬¨?? (or ?¬¢‚Äö?ᬮ??¨tags?¬¢‚Äö?ᬮ¬¨??) to packet sequences so as to define specific, segregated paths for data transmission and to enable traffic to be switched at Layer 2 versus being routed at Layer 3. This significantly accelerates the router lookup function associated with traditional routing. As a by-product, the traffic segregation and static virtual path definition capabilities of MPLS can be leveraged to provide VPN services. These carrier-based services define a label set and corresponding ?¬¢‚Äö?ᬮ??¨dedicated?¬¢‚Äö?ᬮ¬¨?? virtual path for site-to-site connectivity between specific enterprise locations. MPLS VPNs are believed to have strong potential for VoIP
services, promising reduced latency and carrier-based call routing. Cisco and Juniper are currently the leading
providers of MPLS-enabled routers.

MPLS VPNs promise improved performance with reduced capital and operational costs ?¬¢‚Äö?ᬮ‚Äö?Ñ?? in reality, they are still more of a carrier traffic engineering mechanism than an enterprise solution today. One of the major issues currently limiting MPLS-based VPN adoption is the lack of cross-carrier interoperability. As a result, deployment is limited to only sites residing on the same carrier network. The limited availability of MPLS often forces long traffic backhauls to MPLS-enabled POPs, adding multiple router hops and latency to data transmissions. While the service availability issue will improve over time, the carrier interoperability issue may not. Additionally, continued debate over an MPLS standard in the standards bodies may also hinder major deployment and
adoption.

SSL VPNs

IT managers face several challenges when using IPSec for remote access. Along with having to configure and support a client on every remote machine, IPSec is also commonly blocked by corporate firewalls, as well as by some broadband service providers attempting to force users to upgrade to premium business services. As a result of these challenges, SSL (Secure Socket Layer) was born. Inherent in most web browsers, SSL provides a clientless and transparent mechanism to securely connect remote users to enterprise resources, including web-base, client-server and mainframe applications. This eliminates the administrative burden of manually configuring each client machine, greatly simplifies user access (via a familiar browser interface), and enables
access to enterprise resources from any Internet-connected computer, not just corporate-issued laptops. Users simply enter the URL of the SSL VPN gateway at the enterprise site, authenticate via username and password, and gain access to authorized resources.

Additionally, SSL VPNs utilize SSL port 443 (HTTPs) for data transmission, a port that is typically open, as well as highly secured and monitored, on corporate firewalls. This eliminates the firewall traversal issue that IPSec often encounters, as well as IPSec filtering by broadband service providers and ISPs. SSL VPNs allow enterprises to set very granular application-level access control policy (acting as a reverse proxy to application servers), as opposed to node-level policy provided by traditional VPNs. A range of startups have emerged with SSL VPN solutions, with newcomer Neoteris (www.neoteris.com) and established SSL player Aventail (www.aventail.com) among the leaders in this emerging category.

Too Many Options?

While the sheer volume of acronyms and VPN approaches may seem daunting, choosing the option or options that are right for your enterprise does not have to be. Depending on what you are trying to accomplish, there are different paths that can be taken. The matrix below steps through which solutions deliver on a range of common VPN goals:

Whether you choose to augment/extend your existing network infrastructure or are interested in replacing your current WAN entirely, there is a VPN solution that can help lay the foundation for achieving these goals. If you are planning an IP Telephony installation, consider either an MPLS or CPE based IPSEC VPN. The MPLS VPN will deliver QoS on top of which you can layer IP voice to reduce most if not all inter-company voice communications which can be as much as 30% of your total voice traffic.

Leave a Reply




design element