VPNs and IPSec: An Introduction

Joe Freeman and Ronald McCarty

Virtual Private Networks (VPNs) allow relatively low-cost Internet links to function, in a limited fashion, as long-haul Wide Area Network (WAN) pipes. VPN technology can also connect mobile users to corporate networks using Internet or private IP network connections. In both cases, VPN technology takes advantage of low-cost local connections to the Internet, reducing telecommunications costs incurred with traditional wide area connections and long distance dial-in.

Some implementations of VPNs rely on "tunneling" or encapsulation of the data (payload) and header. Tunneling has traditionally been used to route non-supported protocols through particular network segments and to connect two LANs separated by a network that should not directly route the traffic based upon the data's destination address. For example, many university campuses have tunneled IPX across IP backbones to connect the networks without directly supporting IPX on the backbone.

Whatever the motivation for creating the VPN, however, security is a primary concern. Data traveling over the Internet connection should have the same level of security when traversing a private WAN. This article introduces IP Security technology, one of the methods being used to accomplish the security goal, and the implementation considerations.

IP Security, or IPSec, is a series of IETF-proposed standards and drafts that define how network security should be implemented at the network layer of the OSI model. IPSec is an evolving set of standards that is managed by the Internet Engineering Task Force (IETF) IPSec Working Group (IPSec WG). RFC 2401, "Security Architecture for the Internet Protocol," is a good place to start reviewing the technology.

By implementing network security at the network layer, IPSec makes security more transparent to higher layers in the stack. This allows for a standard method within an enterprise of securing data across the network, without relying on multiple operating system vendors, or application vendors, to build data encryption, or authentication into their products. Application level security, despite attempts at standardization, has not gained wide acceptance outside of homogenous systems. Email encryption is a good example: there are client solutions such as Pretty Good Privacy, as well as the mail transport agent with S/MIME (RFC 2311). Although both solutions are sound, their implementation relies on controlling, or at least making assumptions about, the end points of the communication. IPSec can effectively bypass such concerns.

Although tunneling is a mature technology, it is not well known outside the networking community. VPN on the other hand, due to the Internet's popularity, has become a common term for remote users. Unfortunately, VPN technology is often viewed as more art than science, since much of VPN jargon is based upon the encryption and security issues involved. In this article, we will attempt to clarify much of the hyperbole surrounding VPN and explain how IP security can play a role in your organization.

Testing, Testing

Many vendors have entered the VPN market, and more likely than not, you are already using some of these vendors products in your networks. This article will not concentrate on specific vendor solutions. Check http://www.internetwk.com/VPN/links.htm for a list of IPSEC VPN vendors. Do not hesitate to contact your router and firewall vendors - all the major players are providing VPN solutions. Unfortunately, although IPSec is on the IETF's standard's track; vendor interoperability is not yet a complete reality. Some vendors have been able to support claims of interoperability. The ICSA is currently providing testing and certification of interoperability within the VPN world. ICSA details the results of their test at:

http://www.icsa.net/services/product_cert/ipsec

This hit-and-miss interoperability is not untypical - we've seen vendors play the same games with other technologies such as FastEthernet, xDSL, and even OSPF. Of course to claim IP Security compatibility, vendors should meet the IPSec Working Group's requirements such as support for authentication (authentication header), key management (IP security association key management protocol-ISAKMP), and encryption (encryption header). But before we look at the requirements, let's examine what RFC 2401 states as the objective of IPSec. According to paragraph 2.1, a compliant IPSec implementation should provide "...security services offered includes access control, connectionless integrity, data origin authentication, protection against replays...confidentiality...and limited traffic flow confidentiality." Here are the technical requirements to meet those objectives.

Authentication Header Support - Authentication is the process that allows the two endpoints of a VPN conversation to verify that they are each talking to the node that is really supposed to be the endpoint of their VPN. Methods used to authenticate include shared secret passwords, certificates, and Kerberos.

Key Management - Some method must be defined to allow each endpoint of the VPN pipe to exchange public keys so that each side can understand what the other is saying. In a simple way, key management could be considered the language dictionary for both endpoints.

Encryption - IPSec devices should support the U.S. Data Encryption Standard (DES) algorithm. Many vendors support a technique known as Triple DES, 3DES, or 168-bit DES. This method involves three separate encryption operations on the same data, using a different key each time. A simplistic view of the encryption process would be to consider it a special "language" that only the two end points of the VPN can speak. This "language" is referred to as the encapsulating security payload.

Of course, AH and ESP do not have to be used in the same VPN; however, when using the Internet as the pipe, you typically want to know that the communication is authentic and is not being listened to by others. Keep in mind that there are other VPN solutions. For example, secure shell (ssh) is very popular for host to host connectivity. Its use as a VPN is somewhat limited because of its host-to-host nature. (Interestingly enough, SSH Communications, the developer of ssh has a programming tool kit for IPSec programming. See http://www.ssh.fi/ipsec/ for details.)

Firewall vendors have also developed VPNs support for their particular firewalls. CheckPoint has SecuRemote:

http://www.checkpoint.com

Axent offers Raptor Mobile:

http://www.axent.com/product/rsbu/mobile/default.htm

and Network Associates, who now owns Gauntlet, has recently announced VPN Server 5.0 with IPSec support:

http://www.nai.com/about/news/press/1999/january/011999.asp)

Cisco's PIX offers IPSec support:

http://www.cisco.com/warp/public/778/security/pix/pie_ds.htm

The major advantage of VPNs entering directly through the firewall is the protection afforded to the network by the firewall without opening additional holes. Unfortunately, these solutions have only recently started becoming as flexible as their standalone IP Security counterparts - the products often do not integrate as seamlessly as their IP Security cousins due to authentication issues within the LAN.

Implementing a VPN

There are two common types of VPNs in use today: point-to-site and site-to-site. The techniques used are similar between the two types, however actual implementation is different. A security policy (or security association) is used in both cases; however, the available options are not the same. RFC 2401, paragraph 4.4 and its sub-paragraphs go into great detail on the differences that will likely be supported in future implementations. From an IP perspective, the real difference is the encapsulation: with a point-to-site type of VPN, the source and destination addresses are not encapsulated in the new payload. With a site-to-site type, the encapsulation must include the source and destination address, because the receiving security gateway must know to whom the traffic is destined.

Point-to-site VPNs (host-to-host in RFC 2401 speak) are typically used when an organization has large numbers of mobile or remote employees. In many cases, it makes good business sense to outsource remote access services to someone that does it well and in quantity, like an ISP. Point-to-site VPNs allow the remote or mobile user to run a client that shims their IP stack. This shim connects to the VPN site host via IP over an IP network, such as the Internet. This shim also handles the IPSec processes to make the VPN relatively transparent to the remote or mobile user.

Common issues with point-to-site VPNs include network identification, such as NT domain authentication, as well as name resolution services (DNS, WINS, NIS). Since a remote or mobile user must log into their workstation (typically a laptop) to start the VPN, there is no connection to the NT domain providing account authentication. The user gets an error message on login indicating that NT domain could not be located and cached user profile information will be used. Obviously, this could mean additional load on your helpdesk. Additionally, there must be a provision for name resolution - the resolver configuration used for the Internet will not work in a company network that has correctly set up naming services to hide the internal host names from the outside.

Site-to-site VPNs are used to connect sites of more than one machine to each other. A typical application would be to connect regional sales centers together, so teams in center A would be able to share data with teams in center B. Using an IP network such as the Internet as the transport would remove costs associated with long distance leased lines or permanent virtual circuit for a cloud solution.

Common issues that you should watch for in site-to-site VPNs are globally unique IP addresses and name resolution. Non-unique IP addresses can be "hidden" with NAT routers. Unfortunately, NAT can complicate the network and may raise other issues common with NAT in addition to breaking authentication headers. Global name resolution usually has more political issues involved than technical difficulties - static entries, split (limited) domain, and sub-domains are all possible solutions.

In many cases, networks use Private Network Numbers (RFC1918) on internal networks. Use of these address spaces requires that either Network Address Translation (NAT), a proxy, or application firewall be used before the traffic is sent to the VPN gateway. Any changes in the headers on packets flowing into and out of the network will break authentication headers and will likely log, or trap, an alert through whatever system (syslog, SNMP, etc.) is being used. A common solution is to place the VPN gateway in parallel with the firewall. An even better solution is firewall identification of the packets so that it knows to not touch the traffic.

It is important to consider the type of traffic that you anticipate traveling across the VPN pipe. Some traffic, like voice or video may not work as expected. Voice and video are both sensitive to delay and latency in the network, and many VPN implementations simply will not support the technology as well as a dedicated link. Therefore, it is important to realize the limitations of your VPN and not oversell the solution or over subscribe the available bandwidth. When VPNs become overly complicated, be prepared to spend time with your vendor of choice to make sure the particular solution you want to implement works the way you want it to.

Of course, IPSec may be used across any IP cloud, including internal networks and the Internet. Implementation across the Internet brings concerns about lack of quality of service controls and lack of visibility to the contractual agreements with all ISPs in the path between endpoints. Consideration must be given to bandwidth between sites, as well as to latency across the connection path. Because paths change, it is best to coordinate closely with your ISP to ensure you are using the best paths between your sites. In the best case, your ISP will understand your needs and will attempt to solve bandwidth problems when they arise. In the worst case, a change of provider (or the threat of doing so) may be the only solution if you are determined to follow through with the VPN.

The Plan, The Plan

Network planning is very important in designing VPNs. In many cases, VPN connections can be similar to PVCs in a frame relay cloud. In fact, many of the considerations of designing the meshing of a frame cloud apply to a VPN. Meshing (full or partial) and multiple paths to VPN gateways should be considered. Since VPN technology is still young, routing protocols and multiple routes to networks are not supported by all vendors.

VPNs, regardless of technology, will impact network performance. Generally, latency will be higher than the same unencrypted route because there will be a delay for the hop and processor overhead to encrypt the packet. (The type of encryption used also impacts performance; however, due to the exponential growth of CPU strength, the vendor should be consulted concerning real world benchmarking. In many cases, the better encryption will not necessarily be felt except in those cases where the device is approaching 100% utilization.) Additionally, although trends can be identified, external congestion and outages on the Internet must be accepted. Although the Internet is involved, this is not an excuse for a poorly designed network.

A meshed virtual private network may make more efficient use of available bandwidth between sites. Since one site need only establish a connection to the final destination site, there is no redundant use of bandwidth, nor will additional latency be added by unneeded hops.

In most cases, a partially meshed VPN cloud will be sufficient. However, there may be instances where combinations of fully and partially meshed clouds are required. If your company has regional data centers, you may consider fully meshing the data centers, while only partially meshing the remote sites within a regional data center. (The same design issues and goals involved with frame relay will be seen when designing VPNs.)

As with any WAN, inadequate network architecture may result in your VPN cloud becoming the backbone for your enterprise network. Ideally, you should minimize the traffic flowing across your VPN by optimizing (and adding, if necessary) the resources on both sides of the link. These resources could include file and print servers, application servers, authentication, and name resolution servers. Of course, with multiple routes and meshing of networks, management and troubleshooting may become more complex. The management of the devices should be delegated to the network managers responsible for the traditional networking, because the VPNs will become such an integrated part of the network. If WAN and LAN responsibilities are split within your organization, VPN devices should generally be assigned to your WAN team; however, a good argument against the assignment would be when your LAN team has more router or VPN experience. If your management plan calls for centralized management, then you should plan for out-of-band management, since access to the device will not be possible when the tunnel is down. Protecting the device with packet filtering should be considered, since a VPN device could become a hacker's target.

The Bucks Start Here

We have deliberately left the financial considerations for last in order to not distract from the technical details of the article. When comparing VPNs to WAN links, VPNs will generally be considered the most cost efficient, because a local Internet connection with higher bandwidth costs less than a dedicated WAN connection. However, when considering VPN technology, do not forget the variables included with the VPN, such as the Internet's reliability (you can't expect your ISP to send a tech out to the Atlantic coast to replace that fiber hub), the Internet's congestion, and the hostile activity of some Internet users. These variables should be weighed against the applications you wish to use across the VPN. Non-interactive applications are generally robust enough to deal with outages and congestion. For example, mail transport agents queue their mail and try a later delivery. Interactive applications, on the other hand, can be very difficult to use across a congested link. We also mentioned that network resources should be available on both sides of the link; avoid using the VPN as a backbone for centralized services.

Upcoming quality of service proposals may make many of the concerns of using the Internet as transport for your company's business moot points. When widely available across the Internet, protocols such as the Resource Reservation Protocol (RSVP), should enable VPN devices to request minimum bandwidth guaranties from routers and networks along the paths between sites. Look for new technologies such as Voice over IP to be the driving factor in the implementation of the quality of service features of IPv4. IPv6, however has some built-in quality of service features that may make it more attractive in the future.

We've given you an overview of IPSec to get you up to speed on the technology so you can add it to your bag of solutions. Don't limit your VPNing to just connecting your sites across the Internet; the technology can be used to connect extranets, "tunnel off" labs, provide authentication to services, and perform other tasks we've not mentioned. The sidebar, "Uncommon Uses for Common VPN" provides a few additional ideas on VPN usage.

About the Author

Joe Freeman currently works for Sprint Paranet in Dallas as a Technical Analyst. Previously, Joe worked with networks in the defense industry and in the healthcare industry. His free time is spent fishing, reading, or just spending time with his wife, Sarah, and three kids, Jay, Erica, and Beth. He recently completed his CCDA certification and is currently preparing for the CCIE exams.

Ronald McCarty received his bachelor's degree in Computer and Information Systems at the University of Maryland's international campus at Schwaebisch Gmuend, Germany. After completing his degree, Ron started his network career as network administrator at the Schwaebisch Gmuend campus. He currently works for Software Spectrum, Inc., as a network engineer in the IT&S Network Services Project's team. He spends his free time with his two best friends in the world: his daughter, Janice, and his wife, Claudia.