In my September column VPN Platforms for Internet Service Providers, I surveyed a spectrum of commercially-available VPN products. Shortly thereafter, I received email from Matt Karash, Manager, Marketing & Business Analysis, at Celotek Corp. Matt asked "As I understand it, virtually all managed VPN services available today utilize CPE equipment. . . . Central office VPN equipment should be at least have been beta tested by now. Have you heard any early reports from ISPs?"
Matt's question, along with my own exposure to a couple of new network-based VPN products at The Internet Security Conference (TISC), intrigued me. I decided to contact vendors in this arena and ask to speak with trial or early production customers.
It was no surprise to find few customers ready to speak publicly about their experiences with these emerging "carrier class" products. While a number of top-tier ISPs and telcos are trialing central office VPN products, most are in the "hush hush," pre-service-deployment stage and thus reluctant to tip their hands. Clearly there is significant interest here; it's just too early for public consensus.
What makes a Network-Based VPN product different?
Most VPN hardware is geared for enterprise use or for deployment at the customer's premises. These VPN tunnels end at the enterprise network edge—at a VPN-enabled router, firewall, or security device.
The good news: confidentiality and authentication services can protect every packet that enters or leaves the enterprise network. The bad news: CPE involves up-front investment, recurring management costs, and security expertise.
Some CPE products integrate multiple functions—firewall, VPN, QoS—while others focus on performing a single function well. The dilemma: put all your eggs in one (presumably more easily managed) basket and hope it scales, or deploy several products in sequence for greater flexibility—and complexity. In very large scale, centrally-managed service provider networks with many CPE devices per customer, this CPE-based approach becomes unwieldy.
Some vendors think they may have a better answer for service-provider VPNs: move the VPN tunnel termination into the provider's own network. To build a "network-based VPN," providers will need heftier, more versatile VPN products, suitable for central office use, scalable and manageable for both large numbers of subscriber terminations per customer and large numbers of customers. These products are designed to sit someplace between the subscriber access line termination and the core network, concentrating and aggregating customer traffic headed for the provider's backbone network. This is a convenient place to enforce policies that control access, filter packets, shape traffic, and perform high-speed bulk data encryption.
Sounds Interesting, Tell Me More?
As you might expect, each vendor has its own spin on what it takes to be a network-based VPN product. Let's take a quick look at a few of the new products now under development.
The Compatible Systems IntraPort Carrier supports a variety of tunneling protocols (IPsec, L2TP, PPTP), routing protocols (RIP, OSPF, BGP4), and authentication services (RADIUS, SecurID, X.509 certificates). Initially suited for Frame Relay networks, Compatible Systems also plans to support ATM and MPLS networks.
PSINet is using the IntraPort Carrier-8 as a VPN security gateway on its backbone network to support a new Secure Remote Access service. This service, now in alpha test, available 1Q2K, will support up to 40,000 concurrent tunnels between Compatible's IntraPort Client and the IntraPort Carrier gateway. PSINet chose the IntraPort Carrier primarily because of its scalability in performance, price, and deployment. According the Prasad Tumuluri, Product Manager for Security Services at PSINet, "One advantage of this type of product is that we can start with a 10,000 client license and upgrade as the number of users increase." Tumuluri expects a carrier-class VPN gateway to be suitable for backbone deployment: bigger, more robust hardware. PSINet shied away from offering a CPE-based VPN service because doing so would involve greater expense and management by the customer. "With a core based VPN solution, we can take both of these problems out of the customer's hands," says Tumuluri.
CoSine Communications's IP Service Delivery Platform adds a "service processing layer" between subscriber access line concentrators (frame relay switches, DSLAMs) and the provider's core network. In a presentation made at TISC, Dean Hamilton, CoSine CEO, suggested that scalable, network-based VPNs require a non-stop switch delivering service to thousands of subscribers' networks, automated provisioning of services, tracking and reporting against SLAs, and customer network management tools that allow subscribers to view performance and configure their own priorities and services. CoSine employs "virtual routers" (VRs) that can be independently provisioned to reflect the needs of each subscriber. Traffic from customer VRs is aggregated through service provider VRs to provide core network access. Branch office VPN traffic can arrive "in the clear" on private access lines, while remote access PPTP or IPsec traffic can arrive encrypted, allowing both high-performance tunneling between VRs and integration of dial-up clients or remote CPE.
The Nortel Shasta 5000 Broadband Services Node sits at the subscriber edge of a provider's network, integrating DSL, cable, and dial traffic onto a backbone ATM or IP network. In October, I demonstrated the Shasta 5000's Service Creation System (SCS) during VPN @ TISC. SCS enables subscriber self-provisioning and service provider creation of policies. A profile manager is used to create rule-based policies that include VPNs, firewalls, anti-spoofing, differentiated service marking, traffic policing and traffic shaping. Multiple service policies can be combined to create a service profile—a gold package or a bronze package, for example. The Shasta 5000 can operate as an L2TP LNS or LAC and supports site-to-site IPsec tunnels. Nortel sees network-based security as an enabler for residential broadband: residential users won't tolerate CPE-based VPNs, but "always on" services like DSL and cable increase exposure to hacking.
The Redback Subscriber Management System 1000 is designed for placement at service provider's POP, concentrating traffic from leased lines, DSLAMs, cable modems, and wireless head-ends, then grooming traffic for delivery to the service provider's backbone router. The SMS 1000 can be partitioned into 20 virtual routers. "Dynamic service selection" provisions different service characteristics to subscribers sharing the same backbone connection. "Dynamic provider selection" supports both wholesale and wholesale/retail service provisioning models. Redback's target market includes both tier one and tier three ISPs, but its VPN support is limited to L2TP in LAC, LNS, or tunnel switch mode.
Spring Tide's IP Services Switch 5000 is said to lie in the "service layer" of the public Internet because it performs service processing on individual user traffic flows, based on provisioned authentication, encryption, compression, and CoS/QoS characteristics. The IP Services Switch detects new user traffic flows and performs session-level filtering to map each new flow onto an authorized VPN. Input and output protocol stacks are constructed for each virtual access and backbone network connection, and virtual routers maintain separation between customer networks. The IP Services Switch will support IPsec, L2TP, and PPTP tunnels, with service policies stored in RADIUS or LDAP directories.
The proof is in the pudding
These network-based VPNs sound promising: improved scalability, subscriber-based provisioning, rapid service creation and faster service turn-up. Next spring, we'll check back with early network-based VPN customers to see how well this promise has been fulfilled.
http://www.isp-planet.com/technology/carrier_class_vpns.html
