Virtual Private Networks

Since the advent of the Internet, network administrators have looked for ways to leverage the low-cost, widespread medium to transport data while still providing data integrity and confidentiality to protect the information within the data packets, all while maintaining transparency to the end user. This is where the idea of virtual private networks (VPNs) originated, and the Internet Engineering Task Force (IETF) was engaged to craft the standard protocols and procedures to be used by all vendors to achieve these goals.

Point-to-Point Tunneling Protocol (PPTP), Layer 2 Forwarding (L2F) Protocol, Layer 2 Tunneling Protocol (L2TP), Generic Routing Encapsulation (GRE) protocol, Multiprotocol Label Switching (MPLS) VPN, and Internet Protocol Security (IPSec) are just a few examples of VPN protocols that were defined in their respective RFCs.

IPSec became an obvious choice for the majority of the vendors because of its robust features. It was designed to provide data integrity to ensure that packets have not been modified during transmission, packet authentication to make sure that packets are coming from a valid source, and data encryption to assure confidentiality of the content.

Site-to-site protocols allow a corporation to establish VPN connections between two or more offices so that they can send traffic back and forth using a shared medium such as the Internet. This eliminates the need to have dedicated leased lines to connect the remote offices to the corporate network. GRE, IPSec, and MPLS VPN are some commonly used site-to-site VPN protocols.

On the other hand, the remote-access protocols benefit an organization by allowing mobile users to work from remote locations such as home, hotels, and Internet cafes as if they were directly connected to their corporate network. Corporations do not need to maintain a huge pool of modems and access servers to accommodate remote users. Additionally, they save money by not having to pay for the toll-free numbers and long-distance phone charges. Some commonly used remote-access VPN protocols are PPTP, L2TP, L2F, and IPSec.

As you can see, IPSec can be used as either a site-to-site or remote-access protocol. Furthermore, IPSec can be used in conjunction with other VPN protocols, like GRE and L2TP, to provide enhanced security.

Understanding IPSec

Figure 1-9 shows a simple IPSec VPN topology that the fictional SecureMe Company is looking to deploy. SecureMe wants to ensure that the two locations (Chicago and London) can communicate over the Internet without worrying too much about crackers looking at the data content. In this network diagram, Host A, behind the Chicago router, sends a packet to Host B, behind the London router. When the Chicago router receives the clear-text packet, it encrypts the datagram based on the negotiated security policies and then forwards the encrypted datagram to the other end of the VPN tunnel. The London router receives and decrypts the datagram and eventually forwards it to the destination Host B. Because the cracker does not have the security policies (or keys) to decrypt the packet, he cannot look at the content inside.

IPSec VPN devices go through a series of packet exchanges to negotiate security parameters, as discussed in the next section.

Internet Key Exchange

Internet Key Exchange (IKE) uses the framework provided by the Internet Security Association and Key Management Protocol (ISAKMP) and parts of two other key management protocols, namely Oakley and Secure Key Exchange Mechanism (SKEME). The purpose of IKE, as defined in RFC 2409, "The Internet Key Exchange," is to negotiate different security associations (SAs) by using the available key management protocols.

ISAKMP defines two phases when negotiating an IPSec tunnel. It uses Phase 1 to create a secure and authentic communication channel between the peers. By using this bidirectional channel, also known as the ISAKMP SA, the VPN peers can agree on how the further negotiation should be handled by sending protected messages to one another. Because this is a bidirectional channel, either side can initiate Phase 2 negotiations.

IKE Phase 1

The IPSec implementers have the option to use either main mode or aggressive mode to establish Phase 1 SA. The Cisco Systems implementation of IPSec typically employs main mode for site-to-site tunnels and aggressive mode for remote-access VPN tunnels. This is the default behavior when preshared keys are used as the authentication method.

Main mode goes through six packet exchanges in three round trips to negotiate the ISAKMP SA, while aggressive mode completes the SA negotiation in three packet exchanges. One of the biggest advantages of using main mode is its capability to provide identity protection if preshared key (the most commonly used authentication method) is used. Aggressive mode also provides identity protection if public key encryption is used as the authentication method.

Many different ISAKMP attributes are negotiated in Phase 1. Table 1-2 lists these attributes.

Table 1-2. ISAKMP Attributes
Attribute	Possible Values
Encryption	DES, 3DES, AES 128, AES 192, AES 256
Hashing	MD5 or SHA
Authentication method	Preshared keys, RSA signature, or DSA signature
DH group	1, 2, 5 or 7

Figure 1-10 shows the sequence of events that takes place on a VPN device, such as a Cisco ASA, if a preshared key is employed using main mode in Phase 1.

In the first and second packets, the ISAKMP peers complete their Phase 1 proposal negotiations. In the first packet, the initiator generates a proposal that it considers appropriate to send to the other side. An IPSec vendor may choose to send multiple proposals in this packet. The responder evaluates the received proposal and, if there is a match to one of its configured proposals, sends the accepted proposal back to the initiator in the second packet.

In the third and fourth packets, the initiator and the responder exchange their nonces (randomly generated values) and Diffie-Hellman public values to come up with SKEYID states.

In the fifth and sixth packets, the ISAKMP peers exchange their identity information. They protect this by encrypting the packets using the keying material derived from SKEYID. Thus, in the fifth packet, the initiator sends its identity information to the responder for peer verification. Once the responder validates the peer, it sends out its identity information so that the initiator can also validate the responder. After both peers authenticate each other, the Phase 1 SA is successfully negotiated.

Note

Using Preshared key is a widely deployed authentication method for small and medium-sized VPN deployments. RSA signatures, commonly referred to as certificates, provide a scalable and secure environment in which to authenticate VPN peers.

IKE Phase 2

As previously mentioned, after the ISAKMP SA is established, either VPN device can initiate Phase 2 IPSec tunnel negotiation using quick mode. The IPSec SAs are protected by the ISAKMP SA. This means that all payloads are encrypted except for the ISAKMP header.

A single IPSec SA negotiation always creates two security associations�one inbound and one outbound. Each SA is assigned a unique security parameter index (SPI) value�one by the initiator and the other by the responder.

Tip

The security protocols (AH or ESP) are Layer 3 protocols and do not have Layer 4 port information. If an IPSec peer is behind a PAT device, the ESP or AH packets are typically dropped. To work around this, many vendors, including Cisco Systems, use a feature called IPSec pass-thru. The PAT device that is IPSec pass-thru capable builds the Layer 4 translation table by looking at the SPI values on the packets.

Many industry vendors, including Cisco Systems, implement another new feature called NAT Traversal (NAT-T). With NAT-T, the VPN peers dynamically discover whether an address translation device exists between them. If they detect a NAT/PAT device, they encapsulate the data packets using UDP port 4500.

Another interesting point is that if the VPN router needs to connect multiple networks over the tunnel, it will need to negotiate twice as many IPSec SAs. Remember, each IPSec SA is unidirectional. So, if three local subnets need to go over the VPN tunnel to talk to the remote network, then six IPSec SAs will be negotiated. IPSec can use quick mode to negotiate these multiple Phase 2 SAs using the single pre-established ISAKMP SA. The number of IPSec SAs can, however, be reduced if source and/or destination networks are summarized.

Many different IPSec attributes are negotiated in quick mode, as shown in Table 1-3.

Table 1-3. IPSec Attributes
Attribute	Possible Values
Encryption	None, DES, 3DES, AES128, AES192, AES256
Hashing	MD5, SHA or null
Identity information	Network, Protocol, Port number
Lifetime	120�2,147,483,647 seconds 10�2, 147, 483, 647 kilobytes
Mode	Tunnel or transport
PFS group	None, 1, 2, or 5

In addition to generating the keying material, quick mode also negotiates identity information. The Phase 2 identity information specifies what network, protocol, and/or port number to encrypt. Hence, the identities can vary anywhere from an entire network to a single host address, allowing a specific protocol and port.

Quick mode goes through three packet exchanges to successfully negotiate the IPSec SA, as shown in Figure 1-11.

In the first quick mode packet, the initiator sends the identity information, IPSec SA proposal, Nonce payload, and the optional Key Exchange (KE) payload in case Perfect Forward Secrecy (PFS) is used. The responder evaluates the received proposal against its configured proposal. If it finds a match, it sends the accepted proposal back to the initiator along with its identity information, nonce payload, and the optional KE payload. The initiator evaluates the responder's proposal and then sends the third packet. The last packet acts as a confirmation that the IPSec SAs have been successfully negotiated and that the VPN devices can start the data encryption process.

IPSec uses two different IP protocols to encapsulate the data over the VPN tunnel. These protocols are discussed in the next section.

IPSec Protocols

IPSec uses Authentication Header (AH) and Encapsulation Security Payload (ESP) to provide data security. These protocols add an IPSec header that provides the necessary information for the VPN peer to decrypt the received packet.

Authentication Header

AH uses IP protocol 51 as defined in RFC 2402, "IP Authentication Header." It provides data integrity by encapsulating traffic to make sure that the packet has not been altered during transmission. It also provides source origination authentication to ensure that packets were originated by the right peer.

As an option, the VPN devices can use AH's antireplay service. The use of this service is determined by the receiver; hence, the sender has no knowledge whether or not the feature is in use. As a result, the sender is required to use the Sequence Number field in the AH header, as shown in Figure 1-12.

Note

The Cisco ASA does not support AH encapsulation.

One of the shortcomings of using AH is its lack of data confidentially (encryption). Thus, data packets are sent in clear text over the VPN tunnel when AH is used.

Note

AH uses a hash function on the entire packet, including the IP header. When the packet passes through a NAT device, the IP header is modified. Consequently, the output of the hash function is different when the packet is received by the other end of the VPN tunnel.

Encapsulation Security Payload

ESP, as defined in RFC 2406, "IP Encapsulating Security Payload (ESP)," uses IP protocol 50 to encapsulate the data packet. ESP provides:

The VPN device adds an ESP header and trailer to the original packet. The ESP header contains an SPI value and a Sequence Number field. The trailer, on the other hand, contains a Padding field, a Pad Length field, Next Protocol field, and an Integrity Check Value (ICV) field. The Padding field is used to ensure that the Authentication Data is aligned on a 4-byte boundary. It is also used to hide the actual length of the payload. The Pad Length field specifies the number of bytes used as padding. The Next Header field indicates what Layer 4 protocol is being carried in the encrypted packet. The optional ICV field is also present if authentication is used.

Figure 1-13 breaks down the ESP header and trailer when transport mode is used. IPSec modes are discussed in the next section.

Note

If AH and ESP are both used in an IPSec transform set, the AH header gets used as the outermost encapsulation.

Table 1-4. Contrasting AH and ESP
Authentication Header	Encapsulation Security Payload
Uses IP protocol 51 for data encapsulation	Uses IP protocol 50 for data encapsulation
Cannot have a NAT device between the VPN peers	Supports NAT device between the peers
Does not provide payload encryption (confidentiality)	Provides payload encryption (confidentiality)
Authenticates the entire packet including the outermost IP header	Does not authenticate the outermost IP header
Adds an AH header on the packet	Adds an ESP header and a trailer on the packet

IPSec Modes

Transport Mode

Transport mode is used to encrypt and/or to authenticate the data packets that are either sourced by or destined to the IPSec termination points. Most of the Cisco VPN products can act as host devices that terminate the clear-text as well as the IPSec connections. L2TP over IPSec and GRE over IPSec tunnel generally use transport mode where the IP packets are also sourced by the VPN device. Transport mode can also be used for management purposes of the VPN devices, because both clear-text and IPSec packets are originated from or destined to them.

When AH is used in transport mode, a new AH header is added between the IP header and the IP payload. The entire IP packet is then authenticated by the AH process, including the newly added AH header, as shown in part A of Figure 1-14.

ESP can also be deployed in transport mode where the original IP payload is encrypted. The authentication mechanism authenticates the ESP header and trailer in addition to the IP payload. The original IP address is kept intact even after encryption. Part B of Figure 1-14 shows an ESP packet in transport mode.

Tunnel Mode

Tunnel mode is used to encrypt and/or authenticate the IP packets when they are originated by the hosts connected behind the VPN device. In the Cisco VPN devices, tunnel mode is the default mode for IPSec.

When AH is used in tunnel mode, two additional headers get added to the original IP packet:

In AH, the entire IP packet is authenticated, including the new headers; thus, if any bit is changed during transmission, the entire packet is discarded by the receiving VPN device. Figure 1-15, part A, shows an AH packet in tunnel mode.

ESP in tunnel mode encrypts the original IP packet and adds an ESP header and trailer and a new IP header, as shown in part B of Figure 1-15. The ESP authentication process is applied to the original IP header and the ESP header. Thus, if there is a NAT device between the IPSec peers, the IPSec tunnel will successfully work.