CISCO VPN SOLUTIONS

Another major component to the secure networking offered by Cisco is the ability to use VPNs to protect data in transition. You would commonly expect to see three types of scenarios of VPN deployment: host-to-network, network-to-network, and host-to-host:

• Host-to-network scenario is commonly used to connect external hosts into the internal network. A classic example is allowing secure access of mobile users to the enterprise internal resources.

• Network-to-network scenario is commonly used to provide a secure interconnect of two or more networks of the same enterprise located in geographically distant locations.

• Host-to-host scenario is the least common of all types of VPNs. The typical deployment situation is establishment of a secure channel between two hosts on the Internet.

Different views exist on what qualities have to be exhibited by a connection for it to be considered a VPN. We generally take a view that VPN should satisfy three criteria: confidentiality, integrity, and availability. The availability factor depends on many external conditions beyond the network administrator's control; thus we concentrate on the first two factors.

Certain texts mistakenly name protocols such as Layer 2 Forwarding (L2F), Layer 2 Tunneling Protocol (L2TP), Generic Routing Encapsulation (GRE), and Point-to-Point Protocol (PPP) as proper VPNs; in fact, they are merely tunneling protocols that do not provide any authentication or encryption of the traffic. If you wish, you can call them unencrypted VPNs.

The perfect example of classic industry standard VPN is, of course, IPSec. Not surprisingly, it is supported by Cisco IOS-based routers since IOS version 11.3 and Cisco secure PIX firewalls since PIXOS version 5.0. In addition, recognizing the growing need for secure communications, Cisco developed a new family of devices dedicated to terminating high-speed VPN connections, namely the Cisco VPN Concentrator series.

Table 2-3 shows the capabilities of the Cisco VPN Concentrator device families. Table 2-4 shows the capabilities of the Cisco PIX firewall family.

Table 2-3: Capabilities of the Cisco VPN Concentrator Device Families

Cisco VPN Concentrator model	3005	3015	3020	3030	3060	3080	5001	5002	5008
Encryption throughput Mbps	4	4	50	50	100	100	45	190	760
Users	200	100	750	1500	5000	10,000	1500	10,000	40,000
Encryption	Software	Software	Software	Hardware	Hardware	Hardware	Hardware	Hardware	Hardware
IOS router	830	900	1700	2600	2691	7400	3725	3745	7200
Throughput Mbps	6	6	8	14	80	120	150	180	225
Tunnels	50	50	100	800	1000	5000	2000	2000	5000

Table 2-4: Capabilities of the Cisco PIX Firewall

PIX Model	501	506E	515E	525	535
Throughput Mbps	3/4.5	17/30	140/140	155/165	440/535
(3DES/128AES)			(VAC+installed)	(VAC+installed)	(VAC+installed)
Simultaneous connections	10	25	2000	2000	2000

Despite the limited processing power of the PIX firewall and IOS router in respect to the encryption, Cisco is not forcing the end user to invest substantially into the extra VPN Concentrator devices. Instead, two types of VPN Accelerator Cards (VACs) are available.

Reasonably priced, the cards offer significant performance increases in the amount of parallel connections handled and the maximum throughput achieved. The additional benefit is achieved through offloading the mathematically intensive part of cryptographic calculations to the hardware processor of the VAC, so the freed CPU cycles are thrown toward the increased firewalling capability.

The first edition VAC card supports standard Data Encryption Standard (DES) and 3DES encryption and can be installed in any PIX family devices from PIX 515 onward. Bear in mind that only one card can be installed. The 168-bit 3DES throughput is increased to a maximum of 100 Mbps and the number of simultaneous tunnels is increased to 2000.

The second edition VAC+ is similar in its function to the predecessor card, but it has a greater processing capability and supports newer 256-bit Advanced Encryption Standard (AES). The maximum VPN throughput is increased to 440 Mbps.

A variety of hardware encryption modules are also available for casual IOS-based routers, as summarized in Table 2-5. These modules are functionally similar to the PIX VACs.

Table 2-5: IOS-Based Routers with VPN Module

VPN Module	Throughput (Mbps)	Encryption	Simultaneous connections
MOD1700-VPN	8	3DES	100
AIM-VPN/BP	10	3DES	300
AIM-VPN/EP	15	3DES	800
AIM-VPN/HP	42	3DES	2000
AIM-VPN/BPII	22	3DES/AES128	800
AIM-VPN/EP II	150	3DES/AES128	800
AIM-VPN/HP II	180	3DES/AES128	2000
NM-VPN/MP	18	3DES	800
AIM-VPN/BPII-PLUS	22	3DES/AES256	800
AIM-VPN/EPII-PLUS	150	3DES/AES256	800
AIM-VPN/HPII-PLUS	180	3DES/AES256	2000

IPSec

In simple terms, you can view IPSec as consisting of three major parts : the Authentication Header (AH), Encapsulated Security Payload (ESP), and Internet Key Exchange (IKE).

Authentication Header

AH (IP protocol 51) is used to ensure the authentication and integrity of the data flow between peers. A message digest is calculated and sent to the end node; this message is derived from the values in both the IP header and the data payload. The receiving end computes another message digest based on the received packet and compares it with the message digest received. If any packet field was modified in transit, such change will be noticed. AH also accounts for the anti-replay service by implementing sliding window on each IPSec node. Cisco supports the standard MD5 and SHA1 message digest functions.

Encapsulated Security Payload

For clients requiring confidentiality of their data flow, ESP (IP protocol 50) presents two possible solutions. A data payload can be encrypted while leaving the header information intact (Transport mode) or a complete packet can be encrypted (Tunnel mode) and new headers added. Tunnel mode provides additional security level since the source and destination addresses of the packet are hidden. Cisco supports DES, 3DES, and AES as standard encryption algorithms.

Internet Key Exchange

IKE is a general purpose security exchange protocol that is used in Phase 1 operation to authenticate IPSec peers and establish a secure channel to protect feature negotiations in Phase 2.

The following functions are performed during IKE Phase 1:

• Authentication and protection of IPSec nodes identities

• Matching IKE Security Association (SA) policy negotiation to protect IKE exchanges

• Authenticated Diffie-Hellman exchange to establish a matching shared secret key, which is a session key for the symmetric cipher (usually 3DES or AES) used for actual traffic encryption

• Tunnel establishment for the IKE Phase 2 negotiation

Phase 2 is used to negotiate the IPSec SAs employed to set up an IPSec tunnel to protect IP traffic. A single Phase 1 SA can be used to negotiate Phase 2 SAs.

The following functions are performed during IKE Phase 2:

• IPSec SA parameter negotiations

• IPSec SA establishment

• Periodical renegotiation of the IPSec SA

• Additional Diffie-Hellman exchange performed for Perfect Forward Secrecy (PFS)

Authentication Methods

Cisco utilizes two forms of authentication methods to authorize the peers who are participating in the IPSec interconnection: Pre-Shared Key (PSK) and x509 certificates.

The first authentication case relies on the proof of possession of a shared secret between two parties eligible for communication. The factor with a potential to compromise the security of this solution is unsafe distribution of the PSK. While it works fine for a limited number of participating hosts involved in the VPN, such a solution does not scale well.

The second method of authentication relies on the RSA public key cryptography used as a part of the x509 standard, where each node is in possession of the public/private part of the certificate. The method relies on the sending node encrypting some pseudorandom data with the other node's public key; such a message can be decrypted only by the possessor of the corresponding private key. The receiving host decrypts such a message and repeats the process vice versa. The Certificate Authority (CA) is of great importance in this situation, particularly in the untrusted environment with a large number of participating hosts. Thus, the peers rely on the trusted third party (CA in our case) to establish the authenticity of the other end.

PPTP

Another classic example of a modern day widely-used VPN is a proprietary PPTP that was developed by Microsoft. The good thing about this protocol is that practically every version of Windows has inbuilt support for it. All major Cisco products have support for PPTP as well. Its introduction started from IOS version 12.0 for 7100/7200 routers and moved to general router platform since version 12.1; PIXOS has supported PPTP since version 5.1. PPTP is generally considered to be less flexible and does not possess the same level of interoperability as IPSec. For example, the encryption of PPTP tunnels can be done only using the RC4 streaming cipher.

However, PPTP is easy to set up and use and is abundant in the real world.

The protocol relies on the TCP connection established between peers for exchanging signaling information, checking the status of the PPTP connection, and providing overall control of the PPTP tunnel. The actual data transition part of the VPN occurs on another layer, where the data packets are first encapsulated inside the PPP packets that are further encapsulated into GRE packets and sent over the network.

Several methods of authentication are supported, including the following:

• Password Authentication Protocol (PAP) Not recommended, as the passwords are sent in cleartext, and therefore can be easily intercepted.

• Challenge Handshake Authentication Protocol (CHAP) Relies on the challenge/response security mechanism for verifying the identity without revealing the secret to the public.

• Shiva PAP (SPAP) An old insecure authentication protocol supported by NT Remote Access Server RAS.

• Microsoft CHAP (MS-CHAPv1) An authentication protocol you are required to select if you plan to use Microsoft Point to Point Encryption (MPPE). It has a long history of vulnerabilities and is not recommended.

• Microsoft CHAP (MS-CHAPv2) A later version of the original MS-CHAPv1 with several major improvements implemented. It is not backward compatible with MS-CHAPv1. This method is still considered to be a rather weak solution, but it's currently the most sensible authentication protocol to be used for PPTP authentication.

Even though Cisco supports Microsoft PPTP VPNs, both Bruce Schneier and Dr. Mudge, who subjected MS-CHAPv1 to a high degree of scrutiny, came to an agreement that this protocol is not suitable for deployment in environments in which security is critical. As for the user and device authentication methodologies, the solutions provided by Cisco go far beyond the authentication protocols used by PPTP and are described in the section to follow.