Understanding Virtual Private Networks, Part II
By: John Collin, <%=company%>, Edinburgh, UK
Contents
VPN scenarios
Remote access VPN architecture
More protection necessary
Extranet/Intranet VPN Architecture
Rapid device development
Reference material
Until recently, organizations that required secure communications networks between geographically separated sites have relied upon dedicated lines supplied by service providers. The introduction of the virtual private network (VPN) has addressed the issues of security and high costs by enabling the use of the public networks without compromising the security of the data transferred across them.
VPN scenarios
VPN technologies have been applied to three general scenarios. (see Figure 1).
The remote access VPN allows employees of an organization to gain access to their corporate networks via a local Internet Service Provider's (ISP) point of presence on a public network. The overriding benefit of using these VPNs is that they eliminate the need for traveling employees to make long distance, expensive calls to their home office. Instead, a local call is placed to a ISP's point of presence and the VPN is formed between the ISP and a network server on the home network.
The Intranet VPN is formed across a public network by creating semi-permanent wide-area network (WAN) connections between two or more of an organization's offices. The use of the public network removes the need to install dedicated lines between sites, thereby reducing costs and allowing the rapid installation of new networks.
An extranet VPN is identical to the Intranet's in construction, but differs in that it connects an organization to external groups, such as business partners, suppliers, or customers.
Remote access VPN architecture
In its most basic form, a remote access VPN consists of a remote device, an L2TP Access Concentrator/L2TP Network Server pair (LAC/LNS) and a host device on the home network (see Figure 2). Other devices may be present within the VPN, depending on the functionality supported by the Layer 2 Tunneling Protocol (L2TP) devices. For example, if the IP components of these devices do not contain firewall and router capabilities, then separate devices supporting these functions may be present between the L2TP devices and the shared network.
This network architecture allows varying levels of security to be achieved by using features of the Point-to-Point Protocol (PPP), L2TP, and Internet Protocol Security (IPSec) protocols as required. For a relatively low-security VPN, a network administrator can rely on the L2TP tunnel endpoint and PPP session authentication to prevent most weak attacks. For a relatively small cost in terms of performance overhead, the use of PPP encryption would greatly decrease the likelihood of data being intercepted and misused.
More protection necessary
If security is of paramount importance, then IPSec can be incorporated within the VPN. Operating in transport mode, the IPSec connection endpoints would be within the IP components of the LAC and LNS devices. Depending upon the hardware resources available, the use of L2TP and IPSec may have an impact upon the performance of the VPN, since together they will increase the processing overhead as well as use up more network bandwidth.
A typical use of such a network may occur when a traveling member of staff wishes to connect their mobile device to their home network. They must first connect to the public switched telephone network and dial a local rate number supplied by their service provider. The service provider's LAC determines the identity of the remote user via the PPP authentication packets. The user's identity is qualified against a database of legal users and, if recognized, the LAC proceeds with establishing a connection.
A check is carried out to see if a tunnel exists between the LAC and the appropriate LNS. If one is already present, a new session is created within the tunnel to carry the remote user's PPP traffic. Otherwise, a new tunnel is created, with the identity of the LAC being checked by the LNS before the new session is created. On completion of their tasks, the remote user terminates the PPP session causing the L2TP session to terminate and also closes the tunnel if no other sessions are left within it.
Extranet/intranet VPN architecture
The configuration of tunnel mode IPSec between two security gateways provides a rapid method of securely connecting multiple host devices on geographically separated networks (see Figure 3). Since all IPSec configuration information is stored on the security gateways, it is easily found and facilitates speedy configuration when granting VPN access to additional hosts. This also has the advantage that backups of configurations are easily maintained.
An alternative approach to constructing an extranet/intranet VPN would be to configure transport mode IPSec on each host device of a network that needs to communicate with a similarly configured host on a remote network (see figure 4).
Since configuration is carried out at each host, management of this type of VPN is impractical in all but the simplest cases. Furthermore, the chance of errors being introduced into the configurations is increased, as is the difficulty of finding them when problems occur.
Another disadvantage of this architecture is the extra bandwidth that is consumed when transmitting the secured packets across the private segments of the network (networks A and B). In situations where multiple transport mode connections are established, the overhead may have a detrimental affect on performance, which decreases the productivity of staff using the private network.
Rapid device development
The increased requirement in business and private sectors to send confidential material over the Internet has driven the demand for VPN products. The market is enthusiastic and the development and supply of VPN solutions has become a time critical activity. In order to take advantage of these market conditions, it is essential that suppliers develop new products as rapidly as possible.
For any given device in a VPN, developing a protocol stack internally is an unsuitable alternative, as competitors will swiftly bring their products to market before the development cycle is complete. For this reason, many suppliers are looking for outsourcing partners of choice to address the market. Spider Software's existing range of products, combined with the recently introduced VPN functionality, makes the construction of new VPN devices far easier. Time to market can be significantly reduced since complete, established protocol stacks are already available.
More than just a software vendor, Spider Software can provide services such as hardware driver development, the porting of existing products to new operating systems, consultancy and product training. Combined, these services allow a customer to speed up new developments and compete against other device vendors when it comes to shipping new products first.
Reference material
The following Requests For Comments are associated with the protocols covered in this document:
RFC 2661, Layer Two Tunnelling Protocol L2TP, M. Townsley et al.
RFC 2401, Security Architecture for the Internet Protocol, S. Kent, R. Atkinson.
RFC 2402, IP Authentication Header, S. Kent, R. Atkinson.
RFC 2406, IP Encapsulating Security Payload (ESP), S. Kent, R. Atkinson.
RFC 2409, The Internet Key Exchange (IKE), D. Harkins, D.Carrel.
RFC 1994, PPP Challenge Handshake Authentication Protocol (CHAP), W. Simpson
About the author:
John Collin is an established member of Spider Software's Core Protocol Development Group. With experience in embedded software engineering, John joined Spider in September 1996 and is now a key player in the VPN Engineering Team. Educated at Northumbria University, Newcastle-upon-Tyne, John graduated with a First Class Honors Degree in Computing for Industry.