This chapter is from the book
This chapter is from the book
This chapter is from the book
Considerations
Before deciding what kind of VPN is right for you, you need to first define your requirements, conduct a risk analysis, and review collateral issues such as long-term support and operational management needs. In the next few sections, we will describe various issues for you to consider.
Key Distribution
Key distribution among your VPN clients and servers should be one of the first security concerns you review. If your keys are compromised, the security of your system is compromised. When we talk about key distribution, we are concerned with two types of keys: symmetric and asymmetric.
It is crucial to be able to distribute symmetric keys securely. Ideally, you should use a secure out-of-band channel or physically access both systems and set keys up yourself.
In most cases, however, this is not an option. If you have to distribute symmetric keys remotely, make sure you at least use SFTP, SCP, or SSL/TLS. (Telnet and FTP are insecure. If you use them, you are potentially giving your keys away to attackers.) You could even go so far as to hire a professional courier or have one of your employees travel to the remote site with the keys on a floppy disk.
Asymmetric keys (which consist of both a public and private key pair) are a different matter. The public key can be transmitted without secrecy, such as with FTP or even email. Public keys by themselves do not offer an attacker anything that can be leveraged to break into your VPN. The secret key should not be transmitted to the remote end at all because it is only needed for decryption.
Although it is completely fine to transfer public keys in nonsecure manners, it is crucial for you to verify that the keys have not been tampered with when they are received. This can be done simply by installing the key as appropriate to your VPN software and then calling up the administrator at the other end of the VPN link and reading the key aloud. If you transmit your key in a way that allows an attacker to modify it, the attacker could perform a man-in-the-middle attack, defeating the security of your VPN.
In short, reliable transmission of the public key is important, though secret transmission is irrelevant. A secret key should never be stored on the remote endpoint of the VPN. If you are not familiar with asymmetric cryptography, see our glossary (Appendix C) for explanation.
Scalability
VPNs, like all pieces of your network infrastructure, must be able to support the traffic you have and be able to scale with the traffic you will support in the future. If you are implementing a VPN only to connect central and branch offices and have a limited growth plan, you are probably not concerned much with scalability because most VPN technologies will provide what you need. If you are rolling out an enterprise-wide VPN service and are supporting many dial-in users, scalability will be near the top of your list of VPN requirements.
Three main issues help define scalability:
Capability to handle more connections
Ease of maintenance and support
Cost
All three of these issues will depend on the VPN you choose and its design. The topology you use can also greatly affect scalability.
Star Topology
We will now examine a sample network-network VPN that has been built using the star topology (see Figure 2.2).
Figure 2.2 The star topology for VPNs.){kind=link}
In the star topology, you have a VPN connection from each remote site to the main VPN hub, Site One. The VPN hub must be able to support n VPN connections, where n is the number of remote sites. Each remote site that wants to communicate securely must send its traffic through the VPN hub in the center.
The main benefit of this model is that adding new sites is straightforward because all configuration changes are made at a central location, the VPN hub. The drawbacks are as follows:
There is a single point of failure. If the hub goes down, all the spokes can no longer communicate.
If performance on the hub suffers, performance for all VPN traffic suffers.
Two nodes that might be geographically close still have to route through the hub to communicate.
Most of the drawbacks can be mitigated by adding more hubs to distribute the load and provide fault tolerance.
Full Mesh Topology
Next, we will review a VPN built using the full mesh topology. In the fully meshed design, each site communicates directly with every other site. Figure 2.3 shows our sample network built as a fully meshed VPN.
){kind=link}
Figure 2.3 The full mesh topology.
Again, this VPN model has several benefits and one main drawback.
The benefits are as follows:
There is no more single point of failure. Sites do not rely on a hub for intra-VPN communication. VPN connectivity is lost to the problematic network, not all networks.
Overall performance is not limited to a single system.
Geographically close sites can now communicate directly.
The drawback is increased maintenance. If you add a new node, you would typically create VPN associations with every other node.
Although this topology has only one drawback, it is a big one. Instead of managing your keys at a central site, you must now manage them on every node. Again, if you have 1,000 nodes, this can be a formidable task.
Note
Some VPN solutions, such as tinc (see Chapter 10, "tinc"), handle routing for you automatically. This probably will not help much with a 1,000-node setup, but it can still save you a lot of time and effort.
Issues
From both of the preceding examples, we see that adding nodes can be a lot of work. Both star and fully meshed topologies need a scalable way to distribute keys in a secure fashion.
Instead of placing keys on each server, one solution some VPNs have implemented is retrieving key information from a centralized source. FreeS/WAN (see Chapter 6, "FreeS/WAN") supports what is called "opportunistic encryption" and is able to pull key information from DNS.
Another issue that might be a problem is routing. You need to be able to propagate routing information (perhaps by running a common IGP routing protocol such as RIP or OSPF within your networks) or be stuck hard-coding routes manually.
Interoperability
VPN software—even products based on open standards and RFCs—has notoriously had problems with interoperability. For example, administrators frequently find that different standards-compliant commercial solutions don't actually work well together or at all. Your interoperability needs can make or break your VPN decision.
First, you must decide whether you will be connecting to VPNs not controlled by you. If you are connecting to devices over which you have no control, it is best to choose a VPN that is standards based for maximum interoperability.
FreeS/WAN is a good choice for interoperability. IPSec is an industry standard for traffic encryption and has been implemented by many different vendors. Although some of the implementations have only partial support for some of its features, usually both sides of the VPN can be configured to use a set of commonly shared features.
FreeS/WAN itself does not use 56-bit DES for encryption; it supports only triple (168-bit) DES as it is currently bundled. Although this was done by the developers to make FreeS/WAN more secure, it can cause compatibility issues with other implementations. Fortunately, most vendors have implemented IPSec to include support for triple DES as well. This is just one example of the possible snags you will find as your try to connect one protocol implementation to another.
Overall, the issue of interoperability boils down to this question: "Will I ever need to communicate with VPN implementations not under my control?" If so, stick with a standards-based solution. If not, interoperability becomes a nonissue. Just make sure to plan far enough ahead so that you are not constantly rethinking your VPN.
Cross-Platform Availability
Another thing to consider is whether your VPN package will need to run on multiple platforms.
Some VPN packages rely on a common interface that is available for many platforms. For example, the universal TUN/TAP driver provides such an interface, which is used by cIPe (see Chapter 9, "cIPe"). As a result, cIPe is less coupled to the underlying architecture, and as soon as the driver is ported to a new platform, cIPe can then be added relatively quickly.
Cost
Fortunately, because Linux is a free OS, costs incurred from building a Linux-based VPN are usually smaller than for other commercial solutions. The costs you will encounter are for the hardware and the Linux installation media, although the installation can be downloaded free from a distribution mirror.
Other operating systems require licensing for the OS as well as per-seat licensing for the VPN software. Linux has none of these licensing requirements. Not only is Linux VPN software free, a number of free firewall and security packages can be used in conjunction with the VPN software to further secure your site. If you were using similar software on commercial OSs, it could get expensive very quickly.
Although Linux VPNs are cheap, client VPN packages for WinTel platforms are scarce, and as a result, they might not be the best choice for end user VPNs (unless your end users are UNIX savvy, which might rule out all but your engineers). Linux VPNs do provide a great solution for network-network VPNs, where end users and their inferior OSs are not directly involved.