Making Sense Of VPN Systems, Standards, And Protocols.
The Internet is now used by all parts of the expanding corporate enterprise, allowing for the proliferation of branch offices, telecommuters, and other external network users. However, the inherent insecurity of the Internet has created more holes to plug and more opportunities for infection or information leaks. Cryptography, virtual private networks (VPNs), and related technologies are evolving to meet security needs, but strained IT organizations often lack the time and expertise to implement them.
These organizations need to focus more on core business functions and less on managing the IT environment. To do so, they are increasingly outsourcing both network connectivity as well as key e-business and enterprise applications. According to market research firm Infonetics, the market for VPN services will exceed $35 billion by 2003, a growth rate of 606 percent between 2000 and 2004. This means service providers like Web hosts, colocation facilities, and managed security service providers are now responsible for protecting mission-critical customer data while accommodating a variety of products and platforms. This calls for highly scalable, interoperable solutions.
As outsourcing increases, the ability of security systems to scale and meet these requirements must also grow. Until recently, most service providers were forced to cobble together partial solutions from enterprise-oriented security solutions--primarily firewalls and VPNs. VPNs are quickly taking hold in an industry looking for easier and less expensive networking solutions. According to statistics from IDC and Infonetics, the purchase of firewall appliances will reach $1.4 billion by the year 2003, while VPN product sales will reach $3.3 billion.
Fueling these sales is an impressive list of VPN virtues. They provide an extremely high level of security using advanced encryption and authentication protocols, yet they are extremely cost-effective compared to traditional leased-line networks. No more expensive 800-numbers or long distance calls to modem banks--with VPNs, remote users can connect to their corporate networks through a local Internet service provider (ISP). VPNs also serve to connect remote offices via the Internet instead of using more expensive private networks such as Frame Relay and dedicated lines. VPNs also benefit from a scalability cost advantage since users can add a virtually unlimited amount of capacity without adding significant infrastructure. A company can replace expensive servers and modem lines with a VPN appliance and a DSL line, and leverage the ISP's infrastructure.
However, in order for VPNs to be effective they must work together with other security products, like firewalls. It's possible to overcome the mutually exclusive features of firewalls and VPNs, but to do so requires an understanding of the underlying challenges and standards that shape VPN technology.
The current standard for network and even dial-up connections is Internet Protocol Security, or IPSec. A very complex protocol, IPSec has become the clear standard, because it provides all of the elements expected of security:
*Authentication, which assures that the user is who she says she is.
*privacy, which means no one can see the data the user is transmitting.
* Non-repudiation, which provides proof that the addressee received the transmission and also prevents play-back attacks.
* Integrity, which means nothing if the transmission was changed in the middle.
Other protocols exist, most notably PPTP and L2TP. Both have some of the key security elements, but neither is as comprehensive and effective as IPSec.
IPSec provides encryption, key management, and ironclad authentication in a way that proprietary remote access solutions can't, making it the only logical choice for the public line requirements of VPNs. It's worth noting that the next level of security standards will likely combine the robustness of L2TP within the security of IPSec.
Clearing Up The Complexity
All of that power makes IPSec an extremely complex protocol. Its basic encryption function alone can stress security hardware and software. And in order to set up a tunnel, IPSec requires more than encryption. It uses public key cryptographic algorithms to provide high security, authenticate each end of the tunnel, and ensure the privacy of data while traveling through the tunnel. Most firewalls offer content filtering and virus scanning features (key security concerns for any enterprise), but such features have the unfortunate side effect of Internet performance degradation. Adding another element, software-based encryption for remote access users is the surest way to bring the firewall to its knees.
Vendors are dealing with these limitations in a variety of ways. Some firewall vendors have turned to hardware-based encryption accelerators to attempt to ease the load of the software-based access control products. Adding hardware to a general-purpose computer can boost VPN performance somewhat, but bus speed and other architectural limits make this an intermediate solution. And when it comes to handling the special demands of remote access users and their encrypted tunnels, it's just not enough. Remote users are constantly logging on and logging off, and each new tunnel requires multiple public key operations. These operations require special-purpose hardware, the Ferraris of the VPN market.
High performance VPN systems and appliances boast a design that incorporates board layout, processor speed, driver optimization, and custom security ASICs for public key operations as well as encryption. Some tests have attributed such devices with product drive performance 5 to 10 times faster than even the hardware-accelerated configurations of software-based products.
In evaluating VPN systems, speed is only part of the story. Manageability is another. If you purchase separate VPN and firewall products, the first thing you need to determine is how to integrate them with one another--as well as with your Network Address Translation (NAT), PKI, and routers. Bringing these functions and subsystems together in a cohesive security system is challenging because there are so many possibilities, restrictions, and incompatibilities.
Consider what happens when separate devices handle the IPSec VPN, the access control(firewall), and NAT. It's easy to get VPN traffic into your network because it's aimed at the VPN gateway. But it's much harder to get the VPN traffic out of the network through the correct device. IPSec services are so secure that they don't mix well with NAT services. A NAT device changing the IP addresses in the middle of a secure tunnel will transform packets in a way that resembles a "man in the middle" attack, thus causing the IPSec connection to fail. And some IPSec protocols, such as AH (authentication header) are fundamentally incompatible with NAT, because they guarantee the packet hasn't been changed.
Even if you find an IPSec protocol scenario that works, you've got other problems. The Internet Key Exchange (IKE) management protocol, which is responsible for the exchange of symmetrical keys required by IPSec, does not authenticate securely through many NAT configurations.
VPNs And Firewalls
There are only two workable solutions: either IPSec has to occur after NAT processing, or the two must occur in the same system, as in integrated hardware VPN/firewall products (see Figure). If the VPN system is outside the firewall, then the firewall cannot differentiate between encrypted and unencrypted traffic--since it's all decrypted before the firewall sees it. You can't build a firewall policy that depends on the traffic being encrypted, since you can't tell. You may end up requiring users to authenticate two, three, or more times because you can't tell who's really at the other end of the line, even if the VPN gateway used digital certificates to authenticate.
However, the other alternative of placing the VPN gateway inside the firewall presents a different problem. In this case, the firewall must allow encrypted. traffic an trust the decrypting VPN device to implement the corporate security policy. A configuration with two systems raises compliance and coordination problems. Will the VPN device support the corporate security policy in the same manner as the firewall? Will the VPN device be synchronized with the firewall as policy changes?
Since IPSec VPN traffic encrypts all the original packet information, including source and destination address and application type, the firewall cannot apply any filtering. It sees only an IP protocol number and must be either allowed or blocked, without knowing any more details regarding the content of the packet. If you want to use perimeter content or virus scanning, you will find these completely useless on IPSec packets when the VPN gateway is inside the firewall.
Separating VPN and firewall functions can also lead to organizational problems. As VPNs and firewalls cross boundary lines between network infrastructure, security, and telecommunications they must be combined and configured to act as one security system that implements a security policy. It is critical that these configurations be under tight control to assure that organizational policies are followed and needs are met. If these functions are broken across multiple systems and multiple areas of responsibility, it is easy for portions of an organization's security policy to fall between the cracks.
What about interoperability testing? ICSA Labs (www.icsalabs.com) conducts the most comprehensive testing, running each product through a battery of tests against products from eight other vendors. The tests even simulate how networks make bandwidth and other changes on the fly. For any VPN user-- especially service providers that must interact with a variety of platforms and products--ICSA-certified equipment gives you at least a fighting, chance of making products work together.
The Virtual Private Network Consortium (www.vpnc.org) provides a list of VPN products that have passed basic and rekeying compliance testing. VPNC itself reminds us that conformance and interoperability are not the same thing. Conformance means only that the product was tested against two different servers and it passed the test on each server. Further exploration indicates that products that passed conformance testing often failed when linked together.
Even with interoperability testing and standards, however, it can be a challenge to make multi-vendor solutions work. These solutions, by nature, are hard to install and maintain because' individual vendors are constantly enhancing and reevaluating their products. With that said, interoperability does indeed exist and vendors spend a considerable amount of time ensuring interoperability to meet customer needs. But, given the state of the market, this is a less than optimal approach. Dealing with different interfaces, capabilities, and multiple vendor relationships can leave the customer with a decentralized, security solution.
A single integrated security device; that brings the VPN, firewall, NAT, and even traffic shaping together in a single management point allows the highest interoperability, compliance with standards, simplicity, and security. Single product security devices can be maintained with a minimum of staff, a minimum of time and cost, and many have approachable, consistent, simple-to-master interfaces. And an integrated VPN/firewall system eliminates concerns over deployment and interoperability while offering the ease of installation and use unavailable in a solution cobbled together using multiple security vendors.
In today's world, where the Internet can connect remote users (and hackers) with corporate data and applications, state-of-the-art security is a requirement. By combining firewall, NAT, and IPSec VPN functionality into a single system, users can achieve the highest level of security in the most manageable implementation. For the IT organization that does not have the resources to address these issues themselves, outsourcing to a service provider that offers managed security services is another viable option.
Chris Roeckl is director of product marketing and alliances at NetScreen Technologies Inc. (Santa Clara, CA).
|Printer friendly Cite/link Email Feedback|
|Title Annotation:||Internet/Web/Online Service Information|
|Publication:||Computer Technology Review|
|Date:||Mar 1, 2001|
|Previous Article:||SAN On The Edge.|
|Next Article:||Application Performance Monitoring Part 2: Client-Based.|