Should your ISP stick with a single vendor solution to deploy VPN services or do multi-vendor systems deliver a better return on investment? Learn how to build a VPN offering around your ISPs short and long-term goals.

by Lisa Phifer Core Competence, Inc. [June 20, 2001]

Those who deploy Virtual Private Networks (VPNs) for Internet-based remote access, Intranets, and Extranets often begin with a single-vendor solution. Focusing on a single vendor product line can reduce capital equipment, training, and support costs. Initial deployment is often faster and simpler because there are fewer interoperability issues to overcome.

Why go multi-vendor?
Over the long-haul, many larger enterprises, service providers, and carriers end up pursuing multi-vendor VPNs:

• Do you need to deal with firewall and routers already deployed in the target network—an embedded base that won’t disappear overnight?
• Is that single vendor product line really the loosely-integrated sum of several acquisitions?
• Does your target market go beyond the range covered by one vendor, requiring you to look elsewhere for cost-effective solutions at the low or high end?
• Do you stick with vendor A even when vendor B introduces newer, better, faster products?
• Is your account big enough that pitting one vendor against another can reduce your cost or speed feature enhancements?

Harmonic shape and form
When business drivers lead you to consider a multi-vendor VPN, what are the consequences? Multi-vendor VPNs raise concerns about interoperability because IPsec and IKE standards offer many options for protocols, modes, authentication methods, key exchanges, encryption algorithms, and message hash algorithms. Even when the complementary options are supported, these specifications are complex and can be interpreted differently.

Because mix and match problems are inevitable, most VPN vendors perform conformance and interoperability testing to mreasure their own gear against rival's equipment. Self-testing starts behind closed doors, in the safety of one's own laboratory.

Most vendors also attend VPN bakeoffs—industry events held every year. The last bakeoff was in September in San Diego. The next is slated for Finland in August, 2001. VPN bakeoffs are not held to publish test results—they are intended to enable self-testing and debugging in a relatively safe setting. If you purchase products from vendors that participate in VPN bakeoffs, your odds of multi-vendor success are greatly improved.

A list of member products awarded the VPNC logo and associated test results are available online. But there is one caveat, VPNC tests for conformance—not interoperability. Products sporting the VPNC logo won't necessarily interoperate with each other.

ICSA Labs, now a division of TruSecure, runs an IPsec Product Certification program intended to promote multi-vendor interoperability. Version 1.0B verifies that certified products support baseline IPsec—ESP with 3DES and SHA-1, and IKE—preshared secret, Diffie-Helman Group 2. In addition, ICSA tests for proper implementation of cryptographic algorithms. Version 1.1 certified products will also be required to demonstrate baseline digital certificate support.

Unlike VPNC, ICSA continuously re-tests products to verify interoperability with all other certified products. Their website states, "Interoperability testing is not a one-time event, but rather requires ongoing testing with present and future peers. Having been awarded the certification is not an end to the process." A table of certified products and test results can be found here. If you're building a multi-vendor VPN, consult the ICSA's Lab Notes to read about pairwise anomalies.


Go to page 2: One Example >