Introduction

A tunnel is essentially just a method for encapsulating one protocol in another. There are many reasons for doing this. In Chapter 15 we will discuss DLSw, which is commonly used to transmit SNA traffic through an IP network. The SNA protocol is not routable, so the tunnel allows you to send this traffic through a scalable routed network.

You can also use tunnels to transmit protocols that are routable, but not fully supported by the network. For example, some organizations find that they need to be able to send IPX through their networks to support legacy applications. But few network engineers are willing to invest the extra time or money required to build native IPX support into their routing core. So this is an ideal situation for using tunnels.

And we often see tunnels for carrying IP traffic through an IP network. The classic example of this is a Virtual Private Network (VPN) that connects two private networks through a public network such as the Internet. But there are other places where it can be useful to tunnel IP in IP.

One of the most common reasons for tunneling IP in IP is to get around architectural problems with dynamic routing protocols. For example, in Chapter 8 we discussed OSPF virtual links. These are effectively just tunnels that let you put routers in different OSPF areas than their physical connections allow.

Another example appears when you need to extend a routing protocol through regions of the network that don't support this protocol. Some WAN carriers provide IP connectivity between customer locations, similar to a public Internet. But the carrier network can't always support the customer's routing protocol and it is often not desirable to mix the carrier and customer routing tables.

Tunnels are extremely useful in lab or test environments where they allow you to emulate more complex network topologies. Further, in lab environments it is sometimes necessary to tunnel test data through a production network to ensure that the testing cannot interfere with the functioning of the production network. We expect to see a lot of tunneling during the migration phases of any future large scale conversions to IPv6.

Most of the examples in this chapter will look at Generic Routing Encapsulation (GRE) tunnels, sometimes with encryption support using IPSec. GRE is an open standard documented in RFCs 1701 and 1702, and updated in RFC 2784. These documents actually describes GRE Version 0, which is the standard version of GRE. There is also a GRE Version 1, which is more commonly called PPTP (Point-to-Point Tunneling Protocol), and is described in RFC 2637. The key different between GRE and PPTP is that PPTP includes a PPP intermediate layer, while GRE directly supports Layer 3 protocols such as IP and IPX. This chapter does not have the space to cover PPTP or its cousins L2TP (Layer 2 Tunneling Protocol) and L2F (Layer 2 Forwarding). These protocols are commonly used in situations where mobile users need to make VPN connections through the public Internet to an enterprise IP network. There are simply too many different variations to adequately cover even the most common configurations.

GRE doesn't use TCP or UDP. Instead, this protocol works directly with the IP layer, using IP Protocol number 47. It includes its own features for verifying delivery and integrity. The GRE packet's payload includes a complete Layer 3 packet with its payload and headers intact. The routers that terminate the tunnel take packets and wrap them in a new IP packet with a GRE header. They forward this GRE packet through the IP network to the router that supports the other end of the tunnel. The receiving router then simply unwraps the encapsulated packet and sends it on its way. To the encapsulated packet, this entire process has taken a single routing hop, even though the GRE packet may have traversed many routers to reach its destination.

There are other common tunnel protocols, such as IP-in-IP, which uses IP protocol number 4. This protocol is an open standard that is documented in RFC 2003. In general we prefer GRE to IP-in-IP because it offers considerably greater flexibility, particularly on Cisco routers.

Tunnels can have packet fragmentation issues. The problem is simply that when you put a second IP header on an existing packet, you get a bigger packet. If the original packet is already at or close to the Maximum Transmission Unit (MTU) packet size that the network can support, putting this packet in a tunnel forces the router to fragment it. Most of the time this is not a problem, but some applications do not cope well with packet fragmentation.

Normally, applications that can't accept packet fragmentation will set the Don't Fragment (DF) bit in the IP header. The router must drop oversized packets that it cannot fragment, but it sends an ICMP message back to the end device to tell it to use a smaller packet size.

The net result is that when you use tunnels, you reduce the effective MTU of your network. This doesn't necessarily cause problems, but it is important to be aware of the consequences.

Internet Protocol Security (IPSEC) is a suite of security related protocols and algorithms documented in RFCs 2401 through 2412 and RFC 2451. This is far more information than we can even summarize in a book like this, so we mention only some of the most immediately relevant points. The RFCs or books such as IPSec: Securing VPNs (RSA Press) are good resources for more information.

The IPSec framework provides features for authenticating and encrypting traffic as well as for securely exchanging encryption and authentication keys. It is designed to work with both IPv4 and IPv6, and can accommodate a variety of different basic encryption, authentication, and key exchange algorithms. This algorithmic independence is one of the essential design criteria of IPSec. It allows you to transparently substitute a new encryption algorithm, for example, if somebody discovers a critical flaw in the old one, or if a new algorithm is more efficient.

IPSec provides security only at the IP layer. This allows it to protect applications and data operating at higher layers of the protocol stack. This is important because it means that you can use IPSec in conjunction with other insecure protocols or applications and, if done properly, achieve a good level of overall security. Also, because IPSec works at the IP layer, you can readily use it with any of the higher layer IP-based protocols such as TCP, UDP, ICMP, multicast, and so forth.

Unfortunately, one of the most confusing things about IPSec is the proliferation of different protocols and algorithms that handle different parts of the key management, authentication, and encryption processes. Therefore, we will briefly explain some of the more common terms and concepts.

Internet Security Association Key Management Protocol (ISAKMP) is essentially a framework for key exchange, a generic set of procedures and packet formats that allow devices to reliably and securely pass encryption and authentication keys to one another. It includes such concepts as the key security association, which defines not only the keys themselves but important parameters such as the specific algorithms to be used and the length of time that this key is valid for. This information is all negotiated by the IPSec end devices when they first establish a session, and periodically updated if the session remains active for a longer period of time.

Internet Key Exchange (IKE) is a specific protocol for securely exchanging keys using the ISAKMP framework. It uses the OAKLEY key determination protocol, which is defined in RFC 2412. OAKLEY distributes keys of arbitrary types for arbitrary algorithms to use. One of the methods that it can use is the Diffie-Hellman (DH) key exchange model.

DH is a mathematical algorithm that uses properties of large prime numbers to allow users to exchange key information in encrypted form. Both devices authenticating a session can calculate a common key based on the encrypted information that they exchange. There are two issues with this algorithm.

The first is that it can be broken by a "man in the middle" attack. This essentially involves somebody intercepting the exchanged key information and rewriting it to create a new valid key with each of the end devices. The various key management protocols get around this problem by using a separate authentication system to validate the exchanged information.

The second problem is that even with authentication, if the prime numbers aren't large enough, it is possible to mathematically deduce the key. To resolve this problem, Cisco routers offer several different DH Groups. Group 1 uses 768-bit values to define the prime numbers, Group 2 uses 1024-bit primes. And, in IOS level 12.1T, Cisco introduced support for Group 5 DH, which uses a 1536-bit value for its prime numbers. With current computing power, if somebody really wants your data, 768- bit values are not very secure. So we recommend using Group 2 or higher.

OAKLEY also supports the Perfect Forward Secrecy (PFS) system. PFS is a system that ensures that even if somebody is able to break one of the keys, this will tell them nothing about any other keys. This is because the keys are not derived from one another. Many of the Cisco commands related to key exchange include a pfs keyword that you can enable, although you need to ensure that the same options are enabled on both peers.

One of the most effective ways of managing large numbers of keys is to implement a Public Key Infrastructure (PKI), which is a paradigm that uses digital certificates to verify the validity of public encryption and authentication keys. They generally use a Certification Authority (CA), which is a trusted server that knows the public encryption keys for a large number of devices.

IPSec uses two important security protocols, the Authenticating Header (AH), and the Encapsulating Security Payload (ESP). These do pretty much what their names suggest. AH includes a cryptographic authentication scheme in the header of the IP packet, which allows you to ensure that the data has not been tampered with in any way, and that it really does come from the right source device. ESP, on the other hand, encrypts the packet's payload for privacy. We recommend that if you are using IPSec, you should use both AH and ESP together. Authentication and encryption clearly serve entirely different but complementary functions, but we believe it is rare to have data that is important enough to warrant implementing either authentication or encryption but not both.

One of the main authentication methods for IPSec makes use of a cryptographic hash function. Hash functions are actually more common than you might think. The simple Cyclic Redundancy Checksum (CRC) field in a packet is essentially just a hash function. The general definition of a hash function is an algorithm that takes a message of arbitrary length and produces an output of fixed length. This output is often called a message digest.

To be useful for authentication, this hash function must make it extremely difficult to generate a two distinct messages that have the same message digest. There are several of these hash functions in existence. The most popular for use with IPSec are Message Digest Version 5 (MD5) and Secure Hash Algorithm (SHA). We have already discussed MD5 in another setting, when we talked about how Cisco routers store passwords internally in Chapter 3. Cryptographic hash functions make excellent password crypts, because the result is always the same length and almost impossible to reverse. If the algorithm is strong, the only way to decrypt the original password is to encrypt a series of systematic guesses and see if any of them match the unknown encrypted string.

The National Institute of Standards and Technology (NIST) developed the SHA as an improvement over MD5. It is generally believed that SHA is somewhat more secure than MD5, although it is a little bit more CPU intensive.

IPSec uses these hash functions to create Hashed Message Authentication Codes (HMAC). The HMAC is effectively an irreversible cryptographic hash function of an original message that has been combined in a nontrivial way with a password. So you need to not only break the hash algorithm, but also the password to reconstruct the original message.

For the actual data encryption, IPSec again offers several different options. Cisco routers only implement 56-bit and 168-bit Data Encryption Standard (DES) encryption. The 56-bit version of DES is the default, while the 168-bit version is often called Triple DES, and has export restrictions outside of North America.

People have developed several other encryption algorithms for use with IPSec. One of the most popular is called Blowfish. This is an unpatented and freely distributable encryption algorithm that is faster than standard DES, and believed to be more secure as well. Other encryption algorithms include International Data Encryption Algorithm (IDEA), CAST-256, and Skipjack. However, Cisco implements only DES and Triple DES.

IPSec has two main modes of operation: tunnel mode and transport mode. In this chapter we will discuss examples of both. Tunnel mode essentially means that IPSec is responsible for operating its own tunnel. IPSec tunnels are modeled on the IP-in-IP tunnel protocol, which we mentioned earlier. As a result, any IPSec exchanges that use transport mode must be purely between the two end devices, while tunnel mode can support routing from devices that are further downstream. In Recipe 12.3, we will show an example where transport mode is used to encrypt traffic in a GRE tunnel. In this case, the GRE traffic always begins and ends on the routers themselves, although the payload of the GRE packets may contain IP packets routed from other downstream devices. Recipe 12.6, on the other hand, shows an example of tunnel mode. In this case, a remote workstation initiates the IPSec connection to the router. But the packets that this workstation sends are destined for end devices on the other side of the router. So tunnel mode is appropriate here.

By default, Cisco routers will use IPSec in tunnel mode. This is because IPSec needs a well-defined starting and ending point for the encryption. So, with transport mode, the source and destination IP addresses must be fixed somehow. This effectively means that transport mode needs to operate inside of another tunnel protocol such as GRE if it is to carry user traffic between routers.