VPN Basics

For many, all a VPN means is encryption. Although being cryptographically secure is certainly a key benefit of IPsec VPNs, you also must ensure that the network performs and behaves as close to a true private network as possible. This generally means it has the following characteristics:

• Quality of service (QoS) Although most backbone providers will tell you QoS is unnecessary in the core of their network (because it is so fast already), QoS at your WAN access link to the Internet might be necessary depending on the utilization of your WAN link and the other applications that use it.
• Routing Without the ability to exchange dynamic routing information on your VPN, VPN sites require static routes to manage connectivity. This doesn't scale at all.
• High performance If users notice a significant performance degradation when they are on the VPN, there is nothing "virtual" about it.
• High availability (HA) If your private network has HA mechanisms in place, chances are your VPN needs them as well.
• Manageability You must be able to configure, manage, and troubleshoot the VPN network just like you would your private WAN.

VPNs exist because they allow multiple (potentially insecure) applications to traverse the VPN unmolested by the network they are traversing. If the only application you use on your network is completely secure (dream on), a VPN might not be necessary.

There is considerable marketing and posturing regarding what gets to be called a VPN. As "VPN" became an industry buzzword, every vendor wanted to declare that it had one. The most inclusive definition of VPN comprises the following:

• IPsec VPNs
• Multiprotocol Label Switching (MPLS)
• Layer 2 WAN technologies such as frame relay and Asynchronous Transfer Mode (ATM)
• Secure Shell (SSH) port forwarding
• Secure Sockets Layer (SSL)/Transport Layer Security (TLS) VPNs
• Tunneling protocols with or without encryption (Generic Route Encapsulation [GRE], Layer Two Tunneling Protocol [L2TP])

In some cases, two of these methods are merged. Generally, this merge includes IPsec and another technology without native cryptographic capabilities such as MPLS, frame relay, ATM, or GRE.

If you are deploying a VPN technology that isn't cryptographically secure, it really becomes a networking issue instead of a security issue. If what you deploy is cryptographically secure but uses SSL or SSH as a transport, it is more of an application issue. Hence, this book focuses on IPsec VPNs running over shared networks. Whether that shared network is a leased line to the Internet or to a frame relay cloud doesn't make a lot of difference.

Should You Secure Your Frame Relay or ATM Cloud?

An interesting point of debate among security folk is whether a frame relay or ATM cloud can be considered "secure." When deciding this for yourself, consider that with a frame relay or ATM cloud, you are trusting the service provider (SP) and all its employees and contractors not to do something malicious with your data. You are also trusting the physical location where your SP's gear resides. These locations often include facilities that many SPs share. Rack space is often separated by "cages" made out of a chain-link fence material. For an appropriately motivated adversary, it would be easy to connect to many of the systems within these facilities. Certainly, it would be no more difficult than getting access to your data as it crosses the various SPs that make up the backbone of the Internet.

Any decision along these lines concerning the security of frame relay or ATM should take into account the value and risk of an asset as discussed in Chapter 2, "Security Policy and Operations Life Cycle." A bank transmitting financial transactions in the clear certainly should add some security to any L2 WAN technology it uses (and, for that matter, the application as well).

IPsec is a type of network layer cryptography, as discussed in Chapter 4, "Network Security Technologies." Several books have been written about IPsec as a technology. These books go into detail explaining the mathematics involved and all the various options and messages. This book, instead, considers IPsec as a black box process, just like any other crypto mechanism advocated in this book. By "black box" I mean that, as a security architect, you simply must ensure IPsec provides confidentiality, integrity, authentication (which it does). Cleartext bits go in, secure bits go out. People with doctorate degrees in cryptography and mathematics poured over these protocols before they were finalized. As such, security architects need only know that there aren't any significant vulnerabilities. If, on the other hand, you are interested in the math and protocol details, by all means pick up an IPsec book or spend some quality time with RFCs 2401 through 2410.

What you do need to know is the best practices for the deployment of the technology. This includes the types of IPsec VPNs, which IPsec features to turn on or off, topology options, design considerations, deployment examples, and outsourcing considerations. These six topics are the focus of the rest of this chapter.