Network Defense by Rik Farrow and Richard Power We were both surprised when many people asked us about Virtual Private Networking (VPN) during the annual Computer Security Institute conference (November 1997). The technology was not new, but the interest in VPN has certainly accelerated. VPNs use encryption to create a secure link between one or more networks, or individual computers and a network. VPNs first appeared as part of the functionality of a handful of firewalls, but have migrated into standalone products and even into some routers. There are really two major reasons for using VPNs. The most popular reason today wasn't historically the first. But by using VPNs, one can leverage the lower cost of using public networks instead of private WAN links or even frame relay. The second, but orignal reason, was to create a private link over an untrusted network. This private link provides additional security by encrypting data, and possibly digitally signing data for integrity. Lets take a closer look at VPNs to see how they work, and more importantly, the underlying security issues. We will also examine ancilliary issues, such as quality of service, which stand in the way of wider use of VPNs as a replacement for private nework links. Firewalls The term Virtual Private Network was coined by TIS, and began showing up several years ago in the products of firewall vendors. Trusted Information System's Gauntlet Firewall, for example, could be configured to encrypt all packets destined for a list of destination networks. The incoming packets from those networks would be decrypted before the packets would leave the firewall and enter the internal network. Standard IP headers are used, which means that nothing special is required for routing encrypted packets across the Internet, or other TCP/IP networks. Other firewall vendors, such as Sun, Check Point, and Raptor, also began including VPN features in their firewalls. Initially this meant that you had to use one vendor's firewall product on both ends of a VPN connection--the different implementations did not interoperate. A side effect of this was that it was difficult to set up a VPN with a company that already had a firewall from a different vendor. A solution to this appeared realtively quickly in the form of IPSEC, a series of RFCs which defined standards for a authentication and encryption headers (RFCs 1825, 1826, 1827, ftp://ds.internic.net/rfc/rfc1825.txt, ftp://ds.internic.net/rfc/rfc1826.txt, etc.) Originally intended as part of IPv6 protocols, IPSEC allows the addition of authentication and encryption into IPv4-based products such as today's firewalls. Key exchange is covered by other, not fully settled standards, such as ISAKMP and Oakley. RSA proposed and sponsored the formation of an consortium for interoperability testing. Many firewall, router, and IP stack vendors joined in an effort to develop proven interoperability. The first phase of testing focused on simply being able to send, receive, and correctly handle the encryption between various products. Later phases deal with other issues, such as the handling of key exchnage. You can view the results of the latest interoperability testing at http://www.rsa.com/rsa/SWAN/swan_test.htm. Tunneling Other approaches to VPNs have appeared more recently. Routers have long had the ability to "tunnel" other protocols over IP by prepending an IP header to the beginning of each packet, a process also known as encapsulation. Tunneling can easily be extended to VPNs with the addition of encryption capabilities. The router recognizes the destination address as a target for encryption, fetches the appropriate key, encrypts the existing packet, adds a new header. The receiving router then removes the encapsulation header, decrypts the packet, and delivers the packet locally. Ascend, IBM, Intel, Network Systems and Digital include encryption capabilities in some or all of their products, as do other network hardware vendors. Products which include hardware encryption devices, or support them as an option, such as Cisco's PIX, can offer higher throughput. Without hardware encryption, the network devices general purpose CPU is used as an encryption engine--a task it is not optimized for. For slow lines (under 64kbits/second), this is not a problem. But as speed of the link increases, hardware encryption by a dedicated device becomes more critical to avoiding delays. Software products which focus only on VPN have just recently become popular. These products sit on top of a workstation running NT or UNIX, and handle the authentication, encryption, and management functions of running a VPN. What is particularly interesting to us is that these product provide a part of the services, just VPN, that are provided by firewall products at comparable prices. It is hard to understand how these products have gained such a foothold by offering less functionality for prices similar to firewall products. Vendors include TimeStep, Red Creek, and Extended Systems. Windows NT also offers a form of VPN through its RAS (Remote Access Service). Point to Point Tunneling Protocol supports either 40 or 128 bit RC4 encryption using Microsoft Point to Point Encryption (MPPE). If you have NT on the remote system, or have added support for PPTP to Windows 95, you can permit remote users, and even remote networks, VPN access without buying additional software. A third party package, ExtendNet, also supports PPTP. Roving Links Gauntlet PC Extender and Checkpoint's SecureRemote are examples of package which can be loaded on laptop, and permit them to participate in VPNs not matter where the laptop connects to the Internet. You could also do this with PPTP, as mentioned. Products for roving users generally run about $70 to $100 per seat, which makes PPTP look pretty good. But is it? Internet Service Providers, such as UUNET, GTE, MCI, and Sprint, have gotten into the VPN market. In some cases, all they are offering are performance guarantees (which we will cover later). In other cases, the service they are selling is a dialup link which will then be encrypted until it reaches the outside of your site. The service provider "transparently" offers encryption and key management as an outsourced service. In the rush to save money by taking advantage of VPNs, many organizations have overlooked the primary reason for VPN--to extend the security perimter of an organization. A VPN is a tunnel, protected from external inspection by encryption, into your organization's network. This tunnel can connect a roving user, or an entire branch office. But the usual assumption is that you consider the roving user or branch office to have the same security controls that you have within your organization. And the same level of trust. And this is often not true. Let's start with the roving user. This user has either installed some VPN software or is relying on the ISP to supply an encrypted tunnel into your organization. The user, being a clever person, has automated the login procedure, so that all he or she has to do is to click an icon, and the rest of setting up the Internet connection and the encrypted tunnel is carried out. Then someone steals the notebook. Oh, oh. Now, the thief has the same access into your organization's network, just by clicking an icon. Some products force the user to enter a password before the product will work (Data Fellows, for example), but others do not. Microsoft's PPTP on Windows 95 will require a login password for network access, but this could have been provided by the user, who then put the notebook into sleep mode. The thief simply wakes up Windows 95, and then can use the already entered password to remotely access the network. When VPN server support is integrated into a firewall product, the tunnel can end at the firewall, not inside of an organization's network. Not all firewall products support this. But the ability to _not_ trust an incoming VPN connection, and to treat it as if it came from an untrusted network, applying the firewall's security policies, is critical to security. Once again, access to an organization's internal networks is focused on the firewall, a security device designed to provide access control. Gauntlet, and Lucent's new firewall, both support this capability. Is It On Now? Let's imagine that you are being really careful. Your notebook's hard drive is encrypted, and never leaves your side unless it is turned off (not just put into sleep mode). You are using an ISP's VPN, with encrytion provided, to ensure that the data you send home will not be sniffed or modified. But can you really rely on the ISP to do this? Suppose that something is wrong at the ISP, say, that the local end of the encrypting tunnel fails to find a key for your communciation. The VPN software cannot communicate with your notebook (remember, this is a totally transparent service provided by the ISP), so the ISP cannot notify you that encryption has failed. The ISP then has two choices: to break the link, or to continue providing you with a connection _but without encryption_. If the ISP simply breaks the link, you won't know what is wrong--it will just appear that the link (or the local POP) is flaky. But if they continue the link, you are not using encryption and have no way of knowing it. This problem of encryption failing can encompass host based solutions as well. Unless the remote access product has a built-in mechanism for warning you that encryption has failed, you have no way of knowing if your communication is actually encrypted. In other words, you only want to use products which guarantee that encryption is enabled, or that the user will be warned by a session will not be protected by encryption. Some products, such as the TIS PC Extender, will drop the link if encryption fails--a failsafe, if somewhat mysterious, approach for the user. Encryption itself is a complex topic, but here are a few points to consider. First, stick with well known, not proprietary encryption algoriths (DES, triple DES, RC4, IDEA as examples). Creating an unbreakable encryption algorithm is not easy, as many desktop product vendors have learned the hard way. Another issue has to do with key length. Each bit of key length doubles the number of possible keys that can be used with an algorithm. While a 40 bit key means that there are 2 to the fortieth keys, the group who won the RSA issued challenge (http://www.rsa.com/rsalabs/97challenge) for a 40 bit key did it in three and a half hours. The 48 bit key challenge, on the other hand, took 313 hours. Current wisdon suggests that you should be using a minimum of 56 bit keys, and that a key length of 80 bits is considered safe for the near future. Note that the default key length for Microsoft's PPTP is 40 bits. Quality of Service For organizations planning to replace expensive leased lines with VPNs over the Internet, there is another concern outside of security. The Internet provides a variable level of service, dependent on factors often outside of an ISP to control. In the case of setting up a form of virtual links to branch offices, some ISPs, such as UUNET or MCI, provide uptime and/or performance guarantees. For example, if you and your branch offices all use the same ISP, the ISP will guarantee a particular level of service, say 99.7% uptime, or refund part of your monthly fee (10% in the case of MCI, and 25% in the case of UUNET). But this guarantee only covers uptime, not throughput. UUNET offers an additional guarantee, that one way delays will not exceed 150 milleseconds, or another 25% will be refunded. With a leased line, you 'own' the media, and won't experience delays unless _you_ saturate the link. In the case of frame relay, you are sharing the communications infrastructure, but your contract should include a committed information rate (CIR) which guarantees a certain level of performance. With the Internet, you either stick to a single vendor (which supplies performance guarantees), or your packets may get stuck in the same traffic jam as kindergartners roving the Web from home. VPNs are an important addition in your defenses, and can be used to save your organization money--lots of money. But you should not lose sight of the main purpose of a VPN--to provide a secure communications link over an untrusted network--in the rush to save money or provide ease of use. Encryption is a complex issue, and the ideal includes products which make it easy to use _and_ foolproof. This column hasn't even touched on an important issue regarding encryption, which is distribution and management of keys. Digital certificates, such as X.509, can solve these problems--but we don't yet have a national, much less an international system for Certificate Authorities. And we haven't talked about what happens to your notebook when you enter a country, such as France or Israel, which does not permit the use of encryption without severe restrictions. Look for more on the issue of Certificate Authorities in a future column. URLs for vendors mentioned: Firewall Vendors: www.checkpoint.com www.incog.com (Sun) www.lucent.com www.raptor.com www.tis.com Router/Network Hardware Vendors: www.ascend.com www.cisco.com www.digital.com www.ibm.com www.intel.com Software-based VPN vendors: www.aventail.com www.datafellows.com www.extendsystems.com www.timestep.com Set of links to useful articles: http://www.computerworld.com/links/971006vpnlinks.html What is S/WAN Faq: http://www.rsa.com/rsalabs/newfaq/q137.html