Fred Avolio, Avolio Consulting, Inc., http://www.avolio.com/
10 February 2001
|
In columns (see http://www.avolio.com/columns/)I have discussed cryptography as it relates to protecting data transmissions between gateways and from remote users or telecommuters to a corporate network. (For example, “Deploying Crypto What Are You Waiting For?” and “Extending the Perimeter: Protecting the Telecommuter and the Road Warrior”.) In this missive, we will look at the dominant standard for virtual private networks, IPsec. We will see what is there, what is not, and I will give recommendations as to what to do. My assumption is the reader is familiar with the need for VPNs (if not, see my previous editorials) and the basic ideas behind them. Therefore I will spend very little space on the basics. VPN and IPsec BasicsVPN technology combines two concepts. The first is virtual networks, in which geographically or topographically distributed users and computers interact and are managed as a single (flat) network. The second is private networks, in which we protect the data from eavesdropping and, perhaps, can trust the identity (ownership, location, administration) of each user and each node on the network. An “Internet goal” is to be able to use VPN technology, not only within a corporate environment, but to extend the use Internet-wide. This would provide for protection of data between enterprises and individuals that had never before established any kind of a relationship. IPsec standards provide for that. There are other vendor- developed standards that try to handle part of the problem set, but IPsec tries to handle the whole, while doing so in a non-vendor-specific way. IPsec is a “product of the IETF, the Internet Engineering Task Force (http://www.ietf.org/). IPsec covers the encryption of network connections for confidentiality and more. It also takes care of the automatic sharing of electronic credentials in order to establish the identity of each end of a network connection, as well as the automatic negotiation necessary for deciding on encryption algorithms to use and the like. What’s ThereIPsec is not in wide spread use in corporations. VPN technology has been a requested feature in networking products for over 7 years, but enterprises have been slow to deploy it. The good news is, the technology has been around and tested for that long, and a long list of IPsec compliant products exist as do interoperability matrices. (See the ICSA IPsec Certified Products list at http://www.icsa.net/.) One can today purchase routers, firewalls, and network appliances, all supporting IPsec VPNs. What’s NotThe bad news is, while interoperability testing has been going on for all this time, there are still interoperability problems. Not all products interoperate, and not all that do, do so in all modes. Also, there are some other speed bumps to get over in IPsec. For example, IPsec deals with computers and networks, not with people. When we talk about “authentication,” we mean “of end points,” not users. Some kind of user-level authentication is needed if we plan on using a VPN to provide access for remote users. Also, since IPsec authentication typically works using an IP address as a distinguished name for identification purposes, it does not work well in a DHCP environment (where IP addresses are dynamically assigned, typical of dial-up connections to ISPs). Lastly, if we are using digital certificates for the end point credentials, we might have to invest in establishing a public key infrastructure (PKI). Fortunately, neither of the first two need come into play if we are establishing VPNs between offices (site-to-site). Client VPN products typically come with a sub-authentication mechanism that requires the user to identify herself to the software before the remote client’s system credentials are unlocked, and server-side software, supporting the client, typically has extended IPsec to use other means besides IP address to establish identity for authentication. And while digital certificates and a PKI may be required for the universal usability of VPNs, most products allow IPsec authentication using preloaded public keys or product-generated digital certificates without requiring a separate PKI. Next StepsSite-to-site VPNs can be deployed now. Client to site VPNs also. IPsec products still have limitations, but those limitations should not stop us from using them, if we go in to it having answers to the proper questions. Is it standards compliant? Who says? With what other products will it interoperate? This last questions is not so important in the near-term if you are deploying on a small scale and standardizing on one vendor’s product, for now. What is the client software administration like? Do you have to handle each user one at a time? In a small shop this may not matter. If you are deploying 1000 seats, it probably will. How is installation for remote users handled? Is the client software easy enough for your users to use? Does it require a PKI and do you have one if it does? There may be some deployment struggles, but if you need to extend the network security perimeter of your corporation anywhere in the world, you need an IPsec VPN. For Further Reading:“VPNs: Virtually Anything?” White paper. Core Competance, Inc., http://www.corecom.com/html/vpn.htmlVirtual Private Network Consortium, http://www.vpnc.org.Smith, Richard, Internet Cryptography, Reading, MA: Addison-Wesley, 1997. ISBN 0201-92480-3. [This previously unpublished column was originally written for WatchGuard Technologies http://www.watchguard.com/.] |