. 10
( 19)


repository for various backup reasons. Usage keys allow the user to back up only the private
key of the encrypting pair. The signing private key remains with the user, enabling true

7.4.5 PKI Standards
Standardization and interoperability of different PKI vendors is still an issue when interconnecting
PKIs. Interoperability between a PKI and its supporting services, such as Lightweight Directory
220 CCNA Security Course Booklet, Version 1.0

Access Protocol (LDAP) and X.500 directories, is a concern because many vendors have proposed
and implemented proprietary solutions instead of waiting for standards to develop. The state of in-
teroperability is very basic, even after 10 years of PKI software development.
To address this interoperability concern, the IETF formed the Public-Key Infrastructure X.509
(PKIX) workgroup, that is dedicated to promoting and standardizing PKI in the Internet. This
workgroup has published a draft set of standards, X.509, detailing common data formats and PKI-
related protocols in a network.
X.509 is a well-known standard that defines basic PKI formats such as the certificate and certifi-
cate revocation list (CRL) format to enable basic interoperability. The standard has been widely
used for years with many Internet applications, such as SSL and IPsec.
The X.509 version 3 (X.509v3) standard defines the format of a digital certificate. Certificates
were traditionally used at the Application Layer to provide strong authentication for applications.
Each application can have a different implementation of the actual authentication process, but they
all use a similar type of certificate in the X.509 format.
This format is already extensively used in the infrastructure of the Internet:

Secure web servers use X.509v3 for website authentication in the SSL and TLS protocols.

Web browsers use X.509v3 to implement HTTPS client certificates in the SSL protocol. SSL

is the most widely used certificate-based authentication. Other well-known applications, such
as Simple Mail Transfer Protocol (SMTP), LDAP, and Post Office Protocol version 3 (POP3)
that were using poor authentication and no encryption, were modified to use SSL.
User mail agents that support mail protection using the Secure/Multipurpose Internet Mail

Extensions (S/MIME) protocol use X.509.
IPsec VPNs where certificates can be used as a public key distribution mechanism for IKE

RSA-based authentication use X.509.
Pretty Good Privacy (PGP) is an application that was originally developed by Phil

Zimmerman, a privacy advocate, so that end users could engage in confidential
communications using encryption. The most frequent use of PGP has been to secure email.
PGP also recognizes the x.509 certificate.
Certificates are also used at the Network Layer or Application Layer by network devices. Cisco
routers, Cisco VPN concentrators, and Cisco PIX firewalls can use certificates to authenticate
IPsec peers.
Cisco switches can use certificates to authenticate end devices connecting to LAN ports. Authenti-
cation uses 802.1X between the adjacent devices. The authentication can be proxied to a central
ACS via the Extensible Authentication Protocol with TLS (EAP-TLS).
Cisco routers can also provide TN3270 support that does not include encryption or strong authen-
tication. Cisco routers can now use SSL to establish secure TN3270 sessions.
Another important PKI standard is the Public-Key Cryptography Standards (PKCS). PKCS refers
to a group of Public Key Cryptography Standards devised and published by RSA Laboratories.
PKCS provides basic interoperability of applications that use public-key cryptography. PKCS de-
fines the low-level formats for the secure exchange of arbitrary data, such as an encrypted piece of
data or a signed piece of data.
As the RSA Laboratories website states, “The Public-Key Cryptography Standards are specifica-
tions produced by RSA Laboratories in cooperation with secure systems developers worldwide for
the purpose of accelerating the deployment of public-key cryptography.”
Chapter 7: Cryptographic Systems 221

Public key technology is increasingly deployed and becoming the basis for standards-based secu-
rity, such as the IPsec and IKE protocols. With the use of public key certificates in network secu-
rity protocols comes the need for a certificate management protocol for PKI clients and CA
servers. These clients and servers can support certificate lifecycle operations, such as certificate
enrollment and revocation and certificate and CRL access.
For example, an end entity starts an enrollment transaction by creating a certificate request using
PKCS #10 (certification request syntax standard) and sends it to the CA that is enveloped using the
PKCS #7(cryptographic message syntax standard). After the CA receives the request, it can per-
form one of three functions:

Automatically approve the request.

Send the certificate back.

Compel the end entity to wait until the operator can manually authenticate the identity of the

requesting end entity.

The end goal is that any network user should be able to request a digital certificate easily and elec-
tronically. Previously, these processes required intensive input from network administrators and
were not suited to large scale deployments. The IETF designed the Simple Certificate Enrollment
Protocol (SCEP) to make issuing and revocation of digital certificates as scalable as possible. The
goal of SCEP is to support the secure issuance of certificates to network devices in a scalable man-
ner using existing technology whenever possible.
SCEP is now being referenced by network equipment manufacturers and software companies who
are developing simplified means of handling certificates for large-scale implementation to every-
day users.

7.4.6 Certificate Authorities
PKIs can form different topologies of trust, including single-root PKI topologies, hierarchical CA
topologies, and cross-certified CA topologies.
Single-root PKI Topology
In the single-root PKI model, a single CA, which is also known as the root CA, issues all the cer-
tificates to the end users. The benefit is simplicity. There are also disadvantages:

It is difficult to scale to a large environment.

It needs a strictly centralized administration.

Using a single signing private key has a critical vulnerability; if this key is stolen, the whole

PKI falls apart because the CA can no longer be trusted as a unique signer.

Because of its simplicity, VPNs that are managed by a single organization often use this topology.
Hierarchical CA Topology
Going beyond the single-root CA, more complex topologies involve multiple CAs within the same
organization. In the hierarchical CA topology, CAs can issue certificates to end users and to subor-
dinate CAs, which in turn issue their certificates to end users, other CAs, or both. In this way, a
tree of CAs and end users is built in which every CA can issue certificates to lower level CAs and
end users.
The main benefits of a hierarchical PKI topology are increased scalability and manageability. Trust
decisions can now be hierarchically distributed to smaller branches. This distribution works well in
222 CCNA Security Course Booklet, Version 1.0

most large organizations. For example, a large company might have a root CA, which issues cer-
tificates to level-2 CAs. These level-2 CAs issue the certificates to the end users. Because the root-
signing key is seldom used after the subordinate CA certificates are issued, the root-signing key is
less exposed and therefore much more trusted. Additionally, if a subordinate CA has its private key
stolen, only a branch of the PKI is rendered untrusted.
One issue with hierarchical PKI topologies lies in finding the certification path for a certificate. It
can be difficult to determine the chain of the signing process. This task increases in difficulty as
more CAs are placed between the root CA and the end user.
Cross-certified CA Topology
Another approach to hierarchical PKIs is called a cross-certified CA or cross-certifying. In this ap-
proach, multiple, flat, single-root CAs establish trust relationships horizontally by cross-certifying
their own CA certificates.
As PKIs are hierarchical in nature, the issuing certificate authority may be a root CA (the top-level
CA in the hierarchy) or a subordinate CA. The PKI might employ additional hosts, called registra-
tion authorities (RAs) to accept requests for enrollment in the PKI. RAs are employed to reduce
the burden on CAs in an environment that supports a large number of certificate transactions or
where the CA is offline.
In a more complex environment, the RA might be tasked with verifying user identity, establishing
passwords for certificate management transactions, submitting enrollment requests along with ap-
propriate organizational attributes or other information to the CA, and handling assorted tasks such
as certificate revocation and re-enrollment.
Usually, these tasks are offloaded to the RA:

Authentication of users when they enroll with the PKI

Key generation for users that cannot generate their own keys

Distribution of certificates after enrollment

It is important to note that the RA only has the power to accept registration requests and forward
them to the CA. It is not allowed to issue certificates or publish CRLs. The CA is responsible for
these functions.
How are certificates retrieved, enrolled, and used in authentication?

7.4.7 Digital Certificates and CAs
In the CA authentication procedure, the first step of the user when contacting the PKI is to se-
curely obtain a copy of the public key of the CA. The public key verifies all the certificates issued
by the CA and is vital for the proper operation of the PKI.
The public key, called the self-signed certificate, is also distributed in the form of a certificate is-
sued by the CA itself. Only a root CA issues self-signed certificates.
To explain how CA certificates are retrieved, consider this example:

Alice and Bob request the CA certificate that contains the CA public key.
Step 1.

Upon receipt of the CA certificate, each requesting system verifies the validity
Step 2.
of the certificate using public key cryptography.
Alice and Bob follow up the technical verification done by their system by
Step 3.
telephoning the CA administrator and verifying the public key and serial number
of the certificate.
Chapter 7: Cryptographic Systems 223

CA certificates are retrieved in-band over a network, and the authentication is done out-of-band
using the telephone.
After retrieving the CA certificate, Alice and Bob submit certificate requests to the CA:

Both systems forward a certificate request that includes their public key along
Step 1.
with some identifying information. All of this information is encrypted using the
public key of the CA.
Upon the receipt of the certificate requests on the CA server, the CA
Step 2.
administrator telephones Alice and Bob to confirm their submittal and the public
key. The CA administrator issues the certificate by adding some additional data
to the certificate request and digitally signing it all.
Either the end user manually retrieves the certificate or SCEP automatically
Step 3.
retrieves the certificate, and the certificate is installed onto the system.
Having installed certificates signed by the same CA, Bob and Alice are now ready to authenticate
each other:

Bob and Alice exchange certificates. The CA is no longer involved.
Step 1.

Each party verifies the digital signature on the certificate by hashing the
Step 2.
plaintext portion of the certificate, decrypting the digital signature using the CA
public key, and comparing the results. If the results match, the certificate is
verified as being signed by a trusted third party, and the verification by the CA
that Bob is Bob and Alice is Alice is accepted.
Authentication no longer requires the presence of the CA server, and each user exchanges their
certificates containing public keys.
PKI as an authentication mechanism has several characteristics:

To authenticate each other, users have to obtain the certificate of the CA and their own

certificate. These steps require out-of-band verification. After this verification is complete, the
presence of the CA is no longer required until one of the involved certificates expires.
Public-key systems use asymmetric keys in which one is public and the other one is private.

One of the features of these algorithms is that whatever is encrypted using one key can only
be decrypted using the other key. This provides nonrepudiation.
Key management is simplified because two users can freely exchange the certificates. The

validity of the received certificates is verified using the public key of the CA, which the users
have in their possession.
Because of the strength of the algorithms that are involved, administrators can set a very long

lifetime for the certificates, typically a lifetime that is measured in years.
The disadvantages of using trusted third parties relate to key management:

A user certificate is compromised (stolen private key).

The certificate of the CA is compromised (stolen private key).

The CA administrator makes an error (the human factor).

224 CCNA Security Course Booklet, Version 1.0

Which type of PKI to implement varies depending on the needs of the organization. Administra-
tors might need to combine public-key authentication with another authentication mechanism to
increase the level of security and provide more authorization options. For example, IPsec using
certificates for authentication and Extended Authentication (XAUTH) with one-time password
hardware tokens is a superior authentication scheme when compared to certificates alone.
Whatever choice the administrator makes, the PKI implementation must be based on the require-
ments specified in the network security policy.
Chapter 7: Cryptographic Systems 225

Chapter Summary
Refer to Packet Refer to
Tracer Activity Lab Activity
for this chapter for this chapter

Your Chapter Note
226 CCNA Security Course Booklet, Version 1.0

Implementing Virtual Private Networks

Chapter Introduction
Organizations use virtual private networks (VPNs) to create an end-to-end private network connec-
tion (tunnel) over third-party networks such as the Internet or extranets. The tunnel eliminates the
distance barrier and enables remote users to access central site network resources. However, VPNs
cannot guarantee that the information remains secure while traversing the tunnel. For this reason,
modern cryptographic methods are applied to VPNs to establish secure, end-to-end, private net-
work connections.
The IP Security (IPsec) protocol provides a framework for configuring secure VPNs and is com-
monly deployed over the Internet to connect branch offices, remote employees, and business part-
ners. It is a reliable way to maintain communication privacy while streamlining operations,
reducing costs, and allowing flexible network administration.
Secure site-to-site VPNs, between central and remote sites, can be implemented using the IPsec
protocol. IPsec can also be used in remote-access tunnels for telecommuter access. The Cisco VPN
Client is one method for establishing the IPsec remote-access VPN. In addition to IPsec, the Se-
cure Sockets Layer (SSL) protocol can be used to established remote-access VPN connections.
In the first hands-on lab for the chapter, Configuring a Site-to-Site VPN Using Cisco IOS and
SDM, learners configure IPsec VPN settings with the CLI on perimeter routers and then verify
IPsec VPN operation. Another site-to-site IPsec VPN is configured and verified using SDM.
In a second hands-on lab, Configuring a Remote Access VPN Server and Client, learners configure
ZPF with SDM on a perimeter router, followed by Cisco Easy VPN Server. Next, Cisco VPN
client is installed and configured on a PC. A remote access VPN connection is then tested.
The labs are found in the lab manual on Academy connection at cisco.netacad.net.
A Packet Tracer activity, Configure and Verify a Site-to-Site IPsec VPN Using CLI, provides learn-
ers additional practice implementing the technologies introduced in this chapter. Learners secure
and test a WAN connection between two remote networks with a site-to-site IPsec VPN. Packet
Tracer activities for CCNA Security are found on Academy Connection at cisco.netacad.net.

8.1 VPNs
8.1.1 VPN Overview
Solutions, such as the various encryption methods and PKI, enable businesses to securely extend
their networks through the Internet. One way in which businesses accomplish this extension is
through Virtual Private Networks (VPNs).
A VPN is a private network that is created via tunneling over a public network, usually the Inter-
net. Instead of using a dedicated physical connection, a VPN uses virtual connections routed
through the Internet from the organization to the remote site. The first VPNs were strictly IP tun-
nels that did not include authentication or encryption of the data. For example, Generic Routing
Encapsulation (GRE) is a tunneling protocol developed by Cisco that can encapsulate a wide vari-
228 CCNA Security Course Booklet, Version 1.0

ety of Network Layer protocol packet types inside IP tunnels. This creates a virtual point-to-point
link to Cisco routers at remote points over an IP internetwork. Other examples of VPNs that do not
automatically include security measures are Frame Relay, ATM PVCs, and Multiprotocol Label
Switching (MPLS) networks.
A VPN is a communications environment in which access is strictly controlled to permit peer con-
nections within a defined community of interest. Confidentiality is achieved by encrypting the traf-
fic within the VPN. Today, a secure implementation of VPN with encryption is what is generally
equated with the concept of virtual private networking.
VPNs have many benefits:

Cost savings - VPNs enable organizations to use cost-effective, third-party Internet transport

to connect remote offices and remote users to the main corporate site. VPNs eliminate
expensive dedicated WAN links and modem banks. Additionally, with the advent of cost-
effective, high-bandwidth technologies, such as DSL, organizations can use VPNs to reduce
their connectivity costs while simultaneously increasing remote connection bandwidth.
Security - VPNs provide the highest level of security by using advanced encryption and

authentication protocols that protect data from unauthorized access.
Scalability - VPNs enable corporations to use the Internet infrastructure that is within

Internet service providers (ISPs) and devices. This makes it easy to add new users, so that
corporations can add significant capacity without adding significant infrastructure.
Compatibility with broadband technology - VPNs allow mobile workers, telecommuters, and

people who want to extend their workday to take advantage of high-speed, broadband
connectivity to gain access to their corporate networks, providing workers significant
flexibility and efficiency. High-speed broadband connections provide a cost-effective solution
for connecting remote offices.
In the simplest sense, a VPN connects two endpoints over a public network to form a logical con-
nection. The logical connections can be made at either Layer 2 or Layer 3 of the OSI model. VPN
technologies can be classified broadly on these logical connection models as Layer 2 VPNs or
Layer 3 VPNs. Establishing connectivity between sites over a Layer 2 or Layer 3 VPN is the same.
A delivery header is added in front of the payload to get it to the destination site. This chapter fo-
cuses on Layer 3 VPN technology.
Common examples of Layer 3 VPNs are GRE, MPLS, and IPsec. Layer 3 VPNs can be point-to-
point site connections such as GRE and IPsec, or they can establish any-to-any connectivity to
many sites using MPLS.
Generic routing encapsulation (GRE) was originally developed by Cisco and later standardized as
RFC 1701. An IP delivery header for GRE is defined in RFC 1702. A GRE tunnel between two
sites that have IP reachability can be described as a VPN, because the private data between the
sites is encapsulated in a GRE delivery header.
Pioneered by Cisco, MPLS was originally known as tag switching and later standardized via the
IETF as MPLS. Service providers are increasingly deploying MPLS to offer MPLS VPN services
to customers. MPLS VPNs use labels to encapsulate the original data, or payload, to form a VPN.
How does a network administrator prevent eavesdropping of data in a VPN? Encrypting the data is
one way to protect it. Data encryption is achieved by deploying encryption devices at each site.
IPsec is a suite of protocols developed with the backing of the IETF to achieve secure services
over IP packet-switched networks. The Internet is the most ubiquitous packet-switched public net-
work; therefore, an IPsec VPN deployed over the public Internet can provide significant cost sav-
ings to a corporation as compared to a leased-line VPN.
Chapter 8: Implementing Virtual Private Networks 229

IPsec services allow for authentication, integrity, access control, and confidentiality. With IPsec,
the information exchanged between remote sites can be encrypted and verified. Both remote-ac-
cess and site-to-site VPNs can be deployed using IPsec.

8.1.2 VPN Topologies
There are two basic types of VPN networks:



A site-to-site VPN is created when connection devices on both sides of the VPN connection are
aware of the VPN configuration in advance. The VPN remains static, and internal hosts have no
knowledge that a VPN exists. Frame Relay, ATM, GRE, and MPLS VPNs are examples of site-to-
site VPNs.
A remote-access VPN is created when VPN information is not statically set up, but instead allows
for dynamically changing information and can be enabled and disabled. Consider a telecommuter
who needs VPN access to corporate data over the Internet. The telecommuter does not necessarily
have the VPN connection set up at all times. The telecommuter™s PC is responsible for establishing
the VPN. The information required to establish the VPN connection, such as the IP address of the
telecommuter, changes dynamically depending on the location of the telecommuter.
Site-to-Site VPN
A site-to-site VPN is an extension of a classic WAN network. Site-to-site VPNs connect entire net-
works to each other, for example, they can connect a branch office network to a company head-
quarters network. In the past, a leased line or Frame Relay connection was required to connect
sites, but because most corporations now have Internet access, these connections can be replaced
with site-to-site VPNs.
In a site-to-site VPN, hosts send and receive normal TCP/IP traffic through a VPN gateway, which
can be a router, firewall, Cisco VPN Concentrator, or Cisco ASA 5500 Series Adaptive Security
Appliance. The VPN gateway is responsible for encapsulating and encrypting outbound traffic
from a particular site and sending it through a VPN tunnel over the Internet to a peer VPN gateway
at the target site. Upon receipt, the peer VPN gateway strips the headers, decrypts the content, and
relays the packet toward the target host inside its private network.
Remote-Access VPN
Remote-access VPNs are an evolution of circuit-switching networks, such as plain old telephone
service (POTS) or ISDN. Remote-access VPNs can support the needs of telecommuters, mobile
users, and extranet consumer-to-business traffic. Remote-access VPNs support a client / server ar-
chitecture where a VPN client (remote host) requires secure access to the enterprise network via a
VPN server device at the network edge.
In the past, corporations supported remote users by using dial-in networks and ISDN. With the ad-
vent of VPNs, a mobile user simply needs access to the Internet to communicate with the central
office. In the case of telecommuters, their Internet connectivity is typically a broadband connec-
In a remote-access VPN, each host typically has Cisco VPN client software. Whenever the host
tries to send traffic intended for the VPN, the Cisco VPN Client software encapsulates and en-
crypts that traffic before sending it over the Internet to the VPN gateway at the edge of the target
network. Upon receipt, the VPN gateway behaves as it does for site-to-site VPNs.
230 CCNA Security Course Booklet, Version 1.0

An emerging remote-access technology is Cisco IOS SSL VPN. This technology provides remote-
access connectivity from almost any Internet-enabled host using a web browser and its native Se-
cure Sockets Layer (SSL) encryption. SSL VPNs allow users to access web pages and services,
including the ability to access files, send and receive email, and run TCP-based applications with-
out IPsec VPN Client software. They provide the flexibility to support secure access for all users,
regardless of the host from which they establish a connection. This flexibility enables companies
to extend their secure enterprise networks to any authorized user by providing remote-access con-
nectivity to corporate resources from any Internet-enabled host.
SSL VPN currently delivers two modes of access: clientless and thin client. With clientless SSL
VPN, a remote client needs only an SSL-enabled web browser to access HTTP- or HTTPS-en-
abled web servers on the corporate LAN. In a thin client SSL VPN environment, a remote client
must download a small, Java-based applet for secure access of TCP applications that use static port
numbers. UDP is not supported in a thin client environment.
SSL VPNs are appropriate for user populations that require per-application or per-server access
control, or access from non-enterprise-owned desktops. SSL VPNs are not a complete replacement
for IPsec VPNs. IPsec VPNs allow secure access to all of an organization™s client/server applica-
tions. Additionally, SSL VPNs do not support the same level of cryptographic security that IPsec
VPNs support. While SSL VPNs cannot replace IPsec VPNs, in many cases, they are complemen-
tary because they solve different problems. This complementary approach allows a single device to
address all remote-access user requirements.
The primary benefit of SSL VPNs is that they are compatible with Dynamic Multipoint VPNs
(DMVPNs), Cisco IOS Firewalls, IPsec, intrusion prevention systems (IPSs), Cisco Easy VPN,
and Network Address Translation (NAT).
The primary restriction of SSL VPNs is that they are currently supported only in software. The
router CPU processes the SSL VPN connections. The onboard VPN acceleration that is available
in integrated services routers accelerates only IPsec connections.

8.1.3 VPN Solutions
The Cisco VPN product line includes several devices to support remote and site-to-site VPN:

Cisco VPN-enabled routers and switches - A good option for customers of all sizes looking

to take advantage of their existing network infrastructures to deploy VPNs and security while
integrating all services into a single device with the widest selection of WAN and LAN
Cisco PIX 500 Series Security Appliances - Provide robust, enterprise-class, integrated

network security services, including stateful inspection firewall, deep protocol and application
inspection and IPsec VPN. PIX 500 Series Security Appliances are an excellent option for
organizations whose security policies recommend separate management of the security
infrastructure to set a clear demarcation between security and network operation. The Cisco
PIX 500 Series is End-of-Sale (EOS). This means it is no longer being sold; however, there is
a large installed base.
Cisco ASA 5500 Series Adaptive Security Appliances - All-in-one security appliances that

deliver enterprise-class security and IPsec VPN to small- and medium-sized businesses and
large enterprise networks in a modular, purpose-built appliance. The appliances incorporate a
wide range of integrated security services, including firewall, IPS, and VPN. Cisco ASA 5500
Series Appliances are ideal for clients who are looking for a robust firewall combined with
comprehensive VPN support.
Chapter 8: Implementing Virtual Private Networks 231

Cisco VPN 3000 Series Concentrators - Offer both IPsec and SSL VPN connectivity on a

single platform without the expense of individual feature licensing. Cisco VPN 3000 Series
Concentrators are EOS.
SOHO routers - Many newer broadband home routers such as Linksys also support VPNs.

In most networks, devices are already in place. If this is the case, it is necessary to verify if inter-
operability among the different devices is possible. For example, a customer network might have a
Cisco ASA 5500 Series Adaptive Security Appliance at one site and a Cisco router at another. This
site-to-site VPN interoperability is possible by choosing, at a minimum, the following software
versions: Cisco IOS Release 12.2(8)T and Cisco ASA 5500 Series Adaptive Security Appliance
Version 8.0.
With Cisco routers running Cisco IOS software, organizations can deploy and scale site-to-site
VPNs of any topology, from hub-and-spoke to the more complex, fully meshed VPNs. In addition,
the Cisco IOS security features combine the VPN feature set with firewall, intrusion prevention,
and extensive Cisco IOS capabilities, including quality of service (QoS), multiprotocol, multicast,
and advanced routing support.
Cisco provides a suite of VPN-optimized routers. Cisco IOS software for routers combines VPN
services with routing services. The Cisco VPN software adds strong security using encryption and
authentication. These Cisco VPN-enabled routers provide high performance for site-to-site, in-
tranet, and extranet VPN solutions.
The Cisco IOS feature sets incorporate many VPN features:

Voice and Video Enabled VPN (V3PN) - Integrates IP telephony, QoS, and IPsec, providing

an end-to-end VPN service that helps ensure the timely delivery of latency-sensitive
applications such as voice and video.
IPsec stateful failover - Provides fast and scalable network resiliency for VPN sessions

between remote and central sites. With both stateless and stateful failover solutions available,
such as Hot Standby Router Protocol (HSRP), IPsec stateful failover ensures maximum
uptime of mission-critical applications.
Dynamic Multipoint Virtual Private Network (DMVPN) - Enables the auto-provisioning of

site-to-site IPsec VPNs, combining three Cisco IOS software features: Next Hop Resolution
Protocol (NHRP), multipoint GRE, and IPsec VPN. This combination eases the provisioning
challenges for customers and provides secure connectivity between all locations.
IPsec and MPLS integration - Enables ISPs to map IPsec sessions directly into an MPLS

VPN. This solution can be deployed on co-located edge routers that are connected to a Cisco
IOS software MPLS provider edge (PE) network. This approach enables the ISP to securely
extend its VPN service beyond the boundaries of the MPLS network by using the public IP
infrastructure that securely connects enterprise customer remote offices, telecommuters, and
mobile users from anywhere to the corporate network.
Cisco Easy VPN - Simplifies VPN deployment for remote offices and teleworkers. The Cisco

Easy VPN solution centralizes VPN management across all Cisco VPN devices, thus reducing
the management complexity of VPN deployments.

For VPN services, Cisco ASA 5500 Series Adaptive Security Appliances offer flexible technolo-
gies that deliver tailored solutions to suit remote-access and site-to-site connectivity requirements.
These appliances provide easy-to-manage IPsec and SSL VPN-based remote-access and network-
aware, site-to-site VPN connectivity. Businesses can create secure connections across public net-
works to mobile users, remote sites, and business partners.
232 CCNA Security Course Booklet, Version 1.0

As an important component of the Cisco Self-Defending Network, Cisco ASA 5500 Series Adap-
tive Security Appliances provide proactive threat mitigation, control network activity and applica-
tion traffic, and deliver flexible VPN connectivity while remaining cost effective.
Cisco ASA 5500 Series Adaptive Security Appliances offer other services, such as intrusion pre-
vention, Cisco SSL VPN, and advanced integration module (AIM) to enhance the processing capa-
bilities of the appliances. These are some of the features that Cisco ASA 5500 Series Adaptive
Security Appliances provide:

Flexible platform - Offers both IPsec and SSL VPN on a single platform, eliminating the

need to provide parallel solutions. In addition to VPN services, Cisco ASA 5500 Series
Adaptive Security Appliances offer application inspection firewall and intrusion prevention
Resilient clustering - Allows remote-access deployments to scale cost-effectively by evenly

distributing VPN sessions across all Cisco ASA 5500 Series Adaptive Security Appliances and
Cisco VPN 3000 Series Concentrators, without requiring user intervention.
Cisco Easy VPN - Delivers scalable, cost-effective, and easy-to-manage remote-access VPN

architecture. Cisco ASA 5500 Series Adaptive Security Appliances dynamically push the
latest VPN security policies to remote VPN devices and clients, making sure that those
endpoint policies are up to date before a connection is established.
Automatic Cisco VPN Client updates - Enables Cisco VPN Client software operating on

remote desktops to be automatically upgraded.
Cisco IOS SSL VPN - Offers Cisco SSL VPN with clientless and thin client Cisco SSL VPN

VPN infrastructure for contemporary applications - Enables converged voice, video, and

data across a secure IPsec network by combining robust site-to-site VPN support with rich
inspection capabilities, QoS, routing, and stateful failover features.
Integrated web-based management - Provides management of the Cisco ASA 5500 Series

Adaptive Security Appliances using the integrated web-based Cisco Adaptive Security Device
Manager (ASDM). Cisco ASDM manages all security and VPN functions of the appliances.

Each Cisco ASA 5500 Series Adaptive Security Appliance supports a number of VPN peers:

Cisco ASA 5505 - 10 IPsec VPN peers and 25 SSL VPN peers, with a Base license, and 25

VPN peers (IPsec or SSL) with the Security Plus license
Cisco ASA 5510 - 250 VPN peers

Cisco ASA 5520 - 750 VPN peers

Cisco ASA 5540 - 5000 IPsec VPN peers and 2500 SSL VPN peers

Cisco ASA 5550 - 5000 VPN peers

Cisco remote-access VPNs can use four IPsec clients:

Certicom client - A wireless client that is loaded on to wireless personal digital assistants

(PDAs) running the Palm or Microsoft Windows Mobile operating systems. Certicom wireless
client software allows companies to extend critical enterprise applications, such as email and
customer relationship management (CRM) tools, to mobile professionals by enabling
handheld devices to connect to corporate VPN gateways for secure wireless access.
Chapter 8: Implementing Virtual Private Networks 233

Cisco VPN Client software - Loaded on the PC or laptop of an individual, the Cisco VPN

Client allows organizations to establish end-to-end, encrypted VPN tunnels for secure
connectivity for mobile employees or teleworkers. The Cisco Easy VPN feature allows the
Cisco VPN Client to receive security policies from the central site VPN device, the Cisco
Easy VPN Server, when a VPN tunnel connection is made, minimizing configuration
requirements at the remote location.
Cisco Remote Router VPN Client - A Cisco remote router, configured as a VPN client, that

connects small office, home office (SOHO) LANs to the VPN.
Cisco AnyConnect VPN Client - Next-generation VPN client that provides remote users with

secure VPN connections to the Cisco 5500 Series Adaptive Security Appliance running Cisco
ASA 5500 Series Software Version 8.0 and higher or Cisco ASDM Version 6.0 and higher. It
does not connect with a Cisco PIX device or Cisco VPN 3000 Series Concentrator. The Cisco
AnyConnect VPN Client supports Windows Vista, Windows XP, Windows 2000, Mac OS X
(Version 10.4 or later) on either Intel or PowerPC, and Red Hat Linux (Version 9 or later).
To enhance performance and offload the encryption task to specialized hardware, the Cisco VPN
family of devices offers hardware acceleration modules:

AIM - A broad range of Cisco routers can be equipped with AIM. Advanced integration

modules are installed inside the router chassis and offload encryption tasks from the router
Cisco IPsec VPN Shared Port Adapter (SPA) - Delivers scalable and cost-effective VPN

performance for Cisco Catalyst 6500 Series Switches and Cisco 7600 Series Routers. Using
the Cisco 7600 Series/Catalyst 6500 Series Services SPA Carrier-400, each slot of the Cisco
Catalyst 6500 Series Switch or the Cisco 7600 Series Router can support up to two Cisco
Cisco PIX VPN Accelerator Card+ (VAC+) - The PIX Firewall VAC+ delivers hardware

acceleration up to 425 Mb/s of DES, 3DES, or AES IPsec encryption throughput.

8.2 GRE VPNs
8.2.1 Configuring a Site-to-Site GRE Tunnel
Generic routing encapsulation (GRE) is a tunneling protocol defined in RFC 1702 and RFC 2784.
It was originally developed by Cisco Systems for creating a virtual point-to-point link to Cisco
routers at remote points over an IP internetwork.
GRE supports multiprotocol tunneling. It can encapsulate multiple protocol packet types inside an
IP tunnel. Adding an additional GRE header between the payload and the tunneling IP header pro-
vides the multiprotocol functionality. IP tunneling using GRE enables network expansion by con-
necting multiprotocol subnetworks across a single-protocol backbone environment. GRE also
supports IP multicast tunneling. Routing protocols that are used across the tunnel enable dynamic
exchange of routing information in the virtual network.
GRE tunnels are stateless. Each tunnel endpoint keeps no information about the state or availabil-
ity of the remote tunnel endpoint. This feature helps service providers (SPs) provide IP tunnels to
customers who are not concerned about the internal tunneling architecture at the SP end. Cus-
tomers then have the flexibility to configure or reconfigure their IP architecture but still maintain
connectivity. It creates a virtual point-to-point link to routers at remote points over an IP internet-
work. GRE does not include any strong security mechanisms to protect its payload.
234 CCNA Security Course Booklet, Version 1.0

GRE encapsulates the entire original IP packet with a standard IP header and GRE header. A GRE
tunnel header contains at least two 2-byte mandatory fields:

GRE flag

Protocol type

GRE uses a protocol type field in the GRE header to support the encapsulation of any OSI Layer 3
protocol. The GRE header, together with the tunneling IP header, creates at least 24 bytes of addi-
tional overhead for tunneled packets.
There are five steps to configuring a GRE tunnel:
Step 1. Creating a tunnel interface using the interface command.
tunnel 0

Step 2. Assigning the tunnel an IP address.
Step 3. Identifying the source tunnel interface using the tunnel command.

Step 4. Identifying the destination of the tunnel using the tunnel command.

Step 5. Configuring which protocol GRE will encapsulate using the tunnel command.
mode gre

The advantages of GRE are that it can be used to tunnel non-IP traffic over an IP network. Unlike
IPsec, which only supports unicast traffic, GRE supports multicast and broadcast traffic over the
tunnel link. Therefore, routing protocols are supported in GRE.
GRE does not provide encryption. If that is needed, IPsec should be configured.

8.3 IPsec VPN Components and Operation
8.3.1 Introducing IPsec
IPsec is an IETF standard (RFC 2401-2412) that defines how a VPN can be configured using the
IP addressing protocol. IPsec is not bound to any specific encryption, authentication, security algo-
rithms, or keying technology. IPsec is a framework of open standards that spells out the rules for
secure communications. IPsec relies on existing algorithms to implement the encryption, authenti-
cation, and key exchange.
IPsec works at the Network Layer, protecting and authenticating IP packets between participating
IPsec devices (peers). As a result, IPsec can protect virtually all application traffic because the pro-
tection can be implemented from Layer 4 through Layer 7. All implementations of IPsec have a
plaintext Layer 3 header, so there are no issues with routing. IPsec functions over all Layer 2 pro-
tocols, such as Ethernet, ATM, Frame Relay, Synchronous Data Link Control (SDLC), and High-
Level Data Link Control (HDLC).
The IPsec framework consists of five building blocks:

The first represents the IPsec protocol. Choices include ESP or AH.

The second represents the type of confidentiality implemented using an encryption algorithm

such as DES, 3DES, AES, or SEAL. The choice depends on the level of security required.
The third represents integrity that can be implemented using either MD5 or SHA.

The fourth represents how the shared secret key is established. The two methods are pre-

shared or digitally signed using RSA.
Chapter 8: Implementing Virtual Private Networks 235

The last represents the DH algorithm group. There are four separate DH key exchange

algorithms to choose from including DH Group 1 (DH1), DH Group 2 (DH2), DH Group 5
(DH5), and DH Group 7 (DH7). The type of group selected depends on the specific needs.
IPsec provides the framework, and the administrator chooses the algorithms that are used to imple-
ment the security services within that framework. By not binding IPsec to specific algorithms, it
allows newer and better algorithms to be implemented without patching the existing IPsec stan-
IPsec can secure a path between a pair of gateways, a pair of hosts, or a gateway and host. Using
the IPsec framework, IPsec provides these essential security functions:

Confidentiality - IPsec ensures confidentiality by using encryption.

Integrity - IPsec ensures that data arrives unchanged at the destination using a hash algorithm

such as MD5 or SHA.
Authentication - IPsec uses Internet Key Exchange (IKE) to authenticate users and devices

that can carry out communication independently. IKE uses several types of authentication,
including username and password, one-time password, biometrics, pre-shared keys (PSKs),
and digital certificates.
Secure key exchange - IPsec uses the DH algorithm to provide a public key exchange

method for two peers to establish a shared secret key.
Confidentiality is achieved through encryption of traffic as it travels down the VPN. The degree of
security depends on the length of the key of the encryption algorithm. If someone tries to hack the
key through a brute-force attack, the number of possibilities to try is a function of the length of the
key. The time to process all the possibilities is a function of the computer power of the attacking
device. The shorter the key, the easier it is to break. A 64-bit key can take approximately one year
to break with a relatively sophisticated computer. A 128-bit key with the same machine can take
roughly 1019 years to decrypt.
The following are some encryption algorithms and key lengths that VPNs use:

DES - Uses a 56-bit key, ensuring high-performance encryption. DES is a symmetric key

3DES - A variant of the 56-bit DES. 3DES uses three independent 56-bit encryption keys per

64-bit block, providing significantly stronger encryption strength over DES. 3DES is a
symmetric key cryptosystem.
AES - Provides stronger security than DES and is computationally more efficient than 3DES.

AES offers three different key lengths: 128 bits, 192 bits, and 256 bits. AES is a symmetric
key cryptosystem.
Software-Optimized Encryption Algorithm (SEAL) - A stream cipher developed in 1993 by

Phillip Rogaway and Don Coppersmith, which uses a 160-bit key. SEAL is a symmetric key
The next VPN-critical function is data integrity. Assume that a check for $100 is written to Sonya
from Jeremy. The check is then mailed to Sonya but intercepted by an attacker. The attacker
changes the name and amount on the check and attempts to cash it. Depending on the forged qual-
ity of the altered check, the attacker could be successful.
236 CCNA Security Course Booklet, Version 1.0

This scenario applies to VPNs because data is transported over the public Internet. Potentially, this
data could be intercepted and modified. A method of proving data integrity is required to guaran-
tee that the content has not been altered. A data integrity algorithm can provide this guarantee.
Hashed Message Authentication Codes (HMAC) is a data integrity algorithm that guarantees the
integrity of the message using a hash value. At the local device, the message and a shared-secret
key are processed through a hash algorithm, which produces a hash value. This value is appended
to the message, and the message is sent over the network. At the remote device, the hash value is
recalculated and compared to the sent hash value. If the transmitted hash matches the received
hash, the message integrity is verified. However, if they do not match, the message was altered and
is invalidated.
There are two common HMAC algorithms:

HMAC-Message Digest 5 (HMAC-MD5) - Uses a 128-bit shared-secret key. The variable-

length message and 128-bit shared secret key are combined and run through the HMAC-MD5
hash algorithm. The output is a 128-bit hash.
HMAC-Secure Hash Algorithm 1 (HMAC-SHA-1) - Uses a 160-bit secret key. The variable-

length message and the 160-bit shared secret key are combined and run through the HMAC-
SHA-1 hash algorithm. The output is a 160-bit hash.

HMAC-SHA-1 is considered cryptographically stronger than HMAC-MD5. It is recommended
when slightly superior security is important.
When conducting business over long distance, it is necessary to know (authenticate) the individual
at the other end of the phone, email, or fax. The same is true of VPN networks. The device on the
other end of the VPN tunnel must be authenticated before the communication path is considered
In the middle ages, a seal guaranteed the authenticity of a document. In modern times, a signed
document is notarized with a seal and a signature. In the electronic era, a document is signed using
the sender™s private encryption key called a digital signature. A signature is authenticated by de-
crypting the signature with the sender™s public key.
There are two primary methods of configuring peer authentication.

Pre-shared Keys (PSKs) - A pre-shared secret key value is entered into each peer manually

and is used to authenticate the peer. At each end, the PSK is combined with other information
to form the authentication key. Each peer must authenticate its opposite peer before the tunnel
is considered secure. Pre-shared keys are easy to configure manually but do not scale well,
because each IPsec peer must be configured with the pre-shared key of every other peer with
which it communicates.
RSA signatures - The exchange of digital certificates authenticates the peers. The local

device derives a hash and encrypts it with its private key. The encrypted hash is attached to the
message and is forwarded to the remote end and acts like a signature. At the remote end, the
encrypted hash is decrypted using the public key of the local end. If the decrypted hash
matches the recomputed hash, the signature is genuine. Each peer must authenticate its
opposite peer before the tunnel is considered secure.

A third way to accomplish authentication is through RSA-encrypted nonces. A nonce is a random
number that is generated by the peer. RSA-encrypted nonces use RSA to encrypt the nonce value
and other values. This method requires that the public key of the two peers be present on the other
Chapter 8: Implementing Virtual Private Networks 237

peer before the third and fourth messages of an IKE exchange can be accomplished. For this rea-
son, public keys must be manually copied to each peer as part of the configuration process. This
method is the least used of the authentication methods.
Secure Key Exchange
Encryption algorithms such as DES, 3DES, and AES as well as the MD5 and SHA-1 hashing al-
gorithms require a symmetric, shared secret key to perform encryption and decryption. How do the
encrypting and decrypting devices get the shared secret key?
Email, courier, or overnight express can be used to send the shared secret keys to the administra-
tors of the devices. But the easiest key exchange method is a public key exchange method between
the encrypting and decrypting devices.
The Diffie-Hellman (DH) key agreement is a public key exchange method that provides a way for
two peers to establish a shared secret key that only they know, even though they are communicat-
ing over an insecure channel.
Variations of the DH key exchange algorithm are known as DH groups. There are four DH groups:
1, 2, 5, and 7.

DH groups 1, 2, and 5 support exponentiation over a prime modulus with a key size of 768

bits, 1024 bits, and 1536 bits, respectively.
Cisco 3000 clients support DH groups 1, 2, and 5. DES and 3DES encryption support DH

groups 1 and 2.
AES encryption supports DH groups 2 and 5.

The Certicom movianVPN client supports group 7.

Group 7 supports Elliptical Curve Cryptography (ECC), which reduces the time needed to

generate keys.

During tunnel setup, VPN peers negotiate which DH group to use.

8.3.2 IPsec Security Protocols
IPsec is a framework of open standards. IPsec spells out the messaging to secure the communica-
tions but relies on existing algorithms. The two main IPsec framework protocols are AH and ESP.
The IPsec protocol is the first building block of the framework. The choice of AH or ESP estab-
lishes which other building blocks are available:

Authentication Header (AH) - AH, which is IP protocol 51, is the appropriate protocol to use

when confidentiality is not required or permitted. It ensures that the origin of the data is either
R1 or R2 and verifies that the data has not been modified during transit. AH does not provide
data confidentiality (encryption) of packets. All text is transported unencrypted. If the AH
protocol is used alone, it provides weak protection.
Encapsulating Security Payload (ESP) - ESP, which is IP protocol 50, can provide

confidentiality and authentication. It provides confidentiality by performing encryption on the
IP packet. IP packet encryption conceals the data payload and the identities of the ultimate
source and destination. ESP provides authentication for the inner IP packet and ESP header.
Authentication provides data origin authentication and data integrity. Although both
encryption and authentication are optional in ESP, at a minimum, one of them must be
238 CCNA Security Course Booklet, Version 1.0

Authentication Header
AH achieves authenticity by applying a keyed one-way hash function to the packet to create a hash
or message digest. The hash is combined with the text and is transmitted. The receiver detects
changes in any part of the packet that occur during transit by performing the same one-way hash
function on the received packet and comparing the result to the value of the message digest that
the sender supplied. The fact that the one-way hash also involves a shared secret key between the
two systems means that authenticity is assured.
The AH function is applied to the entire packet, except for any mutable IP header fields that
change in transit. For example, Time to Live (TTL) fields that are modified by the routers along
the transmission path are mutable fields.
The AH process occurs in this order:

The IP header and data payload are hashed using the shared secret key.
1. Step 1.

The hash builds a new AH header, which is inserted into the original packet.
2. Step 2.

The new packet is transmitted to the IPsec peer router.
3. Step 3.

The peer router hashes the IP header and data payload using the shared secret
4. Step 4.
key, extracts the transmitted hash from the AH header, and compares the two hashes.
The hashes must match exactly. If one bit is changed in the transmitted packet, the hash output on
the received packet changes and the AH header will not match.
AH supports the HMAC-MD5 and HMAC-SHA-1 algorithms. AH can have problems if the envi-
ronment uses NAT.
ESP provides confidentiality by encrypting the payload. It supports a variety of symmetric encryp-
tion algorithms. If ESP is selected as the IPsec protocol, an encryption algorithm must also be se-
lected. The default algorithm for IPsec is 56-bit DES. Cisco products also support the use of
3DES, AES, and SEAL for stronger encryption.
ESP can also provide integrity and authentication. First, the payload is encrypted. Next, the en-
crypted payload is sent through a hash algorithm, HMAC-MD5 or HMAC-SHA-1. The hash pro-
vides authentication and data integrity for the data payload.
Optionally, ESP can also enforce anti-replay protection. Anti-replay protection verifies that each
packet is unique and is not duplicated. This protection ensures that a hacker cannot intercept pack-
ets and insert changed packets into the data stream. Anti-replay works by keeping track of packet
sequence numbers and using a sliding window on the destination end. When a connection is estab-
lished between a source and destination, their counters are initialized at zero. Each time a packet is
sent, a sequence number is appended to the packet by the source. The destination uses the sliding
window to determine which sequence numbers are expected. The destination verifies that the se-
quence number of the packet is not duplicated and is received in the correct order. For example, if
the sliding window on the destination is set to one, the destination is expecting to receive the
packet with the sequence number one. After it is received, the sliding window moves to two. When
detection of a replayed packet occurs, such as the destination receiving a second packet with the
sequence number of one, an error message is sent, the replayed packet is discarded, and the event
is logged.
Anti-replay is typically used in ESP, but it is also supported in AH.
The original data is well protected by ESP because the entire original IP datagram and ESP trailer
are encrypted. With ESP authentication, the encrypted IP datagram and trailer, and the ESP header,
Chapter 8: Implementing Virtual Private Networks 239

are included in the hashing process. Last, a new IP header is attached to the authenticated payload.
The new IP address is used to route the packet through the Internet.
When both authentication and encryption are selected, encryption is performed first. One reason
for this order of processing is that it facilitates rapid detection and rejection of replayed or bogus
packets by the receiving device. Prior to decrypting the packet, the receiver can authenticate in-
bound packets. By doing this, it can quickly detect problems and potentially reduce the impact of
DoS attacks.
ESP and AH can be applied to IP packets in two different modes, transport mode and tunnel mode.
Transport Mode
In transport mode, security is provided only for the Transport Layer of the OSI model and above.
Transport mode protects the payload of the packet but leaves the original IP address in plaintext.
The original IP address is used to route the packet through the Internet.
ESP transport mode is used between hosts. Transport mode works well with GRE, because GRE
hides the addresses of the end devices by adding its own IP.
Tunnel Mode
Tunnel mode provides security for the complete original IP packet. The original IP packet is en-
crypted and then it is encapsulated in another IP packet. This is known as IP-in-IP encryption. The
IP address on the outside IP packet is used to route the packet through the Internet.
ESP tunnel mode is used between a host and a security gateway or between two security gateways.
For gateway-to-gateway applications, rather than load IPsec on all of the computers at the remote
and corporate offices, it is easier to have the security gateways perform the IP-in-IP encryption and
ESP tunnel mode is used in the IPsec remote-access application. A home office might not have a
router to perform the IPsec encapsulation and encryption. In this case, an IPsec client running on
the PC performs the IPsec IP-in-IP encapsulation and encryption. At the corporate office, the
router de-encapsulates and decrypts the packet.
The VPN process involves selecting and applying many parameters. How does IPsec actually ne-
gotiate these security parameters?

8.3.3 Internet Key Exchange
The IPsec VPN solution negotiates key exchange parameters, establishes a shared key, authenti-
cates the peer, and negotiates the encryption parameters. The negotiated parameters between two
devices are known as a security association (SA).
Security Associations
An SA is a basic building block of IPsec. Security associations are maintained within a SA data-
base (SADB), which is established by each device. A VPN has SA entries defining the IPsec en-
cryption parameters as well as SA entries defining the key exchange parameters.
All cryptographic systems, including the Caesar cipher, Vigenere cipher, Enigma machine, to mod-
ern encryption algorithms, must deal with key management issues. Diffie-Hellman (DH) is used to
create the shared secret key. However, IPsec uses the Internet Key Exchange (IKE) protocol to es-
tablish the key exchange process.
Instead of transmitting keys directly across a network, IKE calculates shared keys based on the ex-
change of a series of data packets. This disables a third party from decrypting the keys even if the
third party captured all exchanged data that is used to calculate the keys.
240 CCNA Security Course Booklet, Version 1.0

IKE is layered on UDP and uses UDP port 500 to exchange IKE information between the security
gateways. UDP port 500 packets must be permitted on any IP interface involved in connecting a
security gateway peer.
IKE is defined in RFC 2409. It is a hybrid protocol, combining the Internet Security Association
and Key Management Protocol (ISAKMP) and the Oakley and Skeme key exchange methods.
ISAKMP defines the message format, the mechanics of a key-exchange protocol, and the negotia-
tion process to build an SA for IPsec. ISAKMP does not define how keys are managed or shared
between the two IPsec peers. Oakley and Skeme have five defined key groups. Of these groups,
Cisco routers support Group 1 (768-bit key), Group 2 (1024-bit key), and Group 5 (1536-bit key).
IKE combines these protocols to build secure IPsec connections between devices. It establishes
SAs that are mutually agreeable to each peer. Each peer must have identical ISAKMP and IPsec
parameters to establish an operational and secure VPN. Note that the terms ISAKMP and IKE are
commonly used by industry people to refer to IKE.
An alternative to using IKE is to manually configure all parameters required to establish a secure
IPsec connection. This process is impractical because it does not scale.
How does IKE work?
To establish a secure communication channel between two peers, the IKE protocol executes two

Phase 1 - Two IPsec peers perform the initial negotiation of SAs. The basic purpose of Phase

1 is to negotiate IKE policy sets, authenticate the peers, and set up a secure channel between
the peers. It can be implemented in main mode (longer, initial contact) or aggressive mode
(after initial contact).
Phase 2 - SAs are negotiated by the IKE process ISAKMP on behalf of IPsec. It can be

negotiated in quick mode.
In Phase 1, the transform sets, hash methods, and other parameters are determined. An IKE session
begins with a router (the initiator) sending a proposals to another router (the responder). The pro-
posal sent by the initiator defines which encryption and authentication protocols are acceptable,
how long keys should remain active, and whether perfect forward secrecy (PFS) should be en-
forced. PFS is a property that states that keys used to protect data are not used to derive any other
keys. PFS ensures that if one key is compromised, previous and subsequent keys remain secure.
Three exchanges transpire during IKE Phase 1. These are referred to as the first, second, and third
First Exchange
The first exchange between the initiator and the responder establishes the basic security policy.
Peers negotiate and agree on the algorithms and hashes that are used to secure the IKE communi-
cations. Rather than negotiate each protocol individually, the protocols are grouped into sets,
called IKE policy sets. The IKE policy sets are exchanged first.
The initiator first transmits proposals for the encryption and authentication schemes to be used.
The responder looks for a matching ISAKMP policy. The responder chooses a proposal that is best
suited to the security situation and then sends that proposal to the initiator. If a policy match is
found between the peers, IKE Phase 1 continues. If no match is found, the tunnel is torn down.
Policy set numbers are only locally significant to a VPN device. The policy set numbers do not
have to match between two VPN peers. In a point-to-point application, each end might need only a
single IKE policy set to be defined. In a hub-and-spoke environment, the central site might require
multiple IKE policy sets to satisfy all the remote peers.
Chapter 8: Implementing Virtual Private Networks 241

Second Exchange
The second exchange creates and exchanges the DH public keys between the two endpoints. DH
allows two parties that have no prior knowledge of each other to establish a shared secret key over
an insecure communications channel.
The two peers run the DH key exchange protocol to acquire the keying material that is needed by
the various encryption and hashing algorithms upon which IKE and IPsec will ultimately agree.
Several levels of DH key exchanges are available in Cisco IOS Software:

DH Group 1 - results in 768 bits of keying material. This group is the usual choice when the

encryption algorithm is DES.
DH Group 2 - results in 1024 bits of keying material. This group is the usual choice when

using 3DES for encryption.
DH Group 5 - results in 1536 bits of keying material. DH 5 should be used with AES.

DH Group 7 (elliptic curve cryptography [ECC]) - generates IPsec keys when the elliptic

curve field is 163 bits. This group was designed to be used with low-powered hosts such as
It is important to have sufficient keying material for the algorithms chosen. Using the DH algo-
rithm, each peer generates a shared secret without actually exchanging secrets. All further negotia-
tions are encrypted using the DH-generated secret key.
Third Exchange
Each end device must authenticate the other end device before the communication path is consid-
ered secure. The last exchange of IKE Phase 1 authenticates the remote peer.
The initiator and recipient authenticate each other using one of the three data-origin authentication


RSA signature

RSA encrypted nonce

The Phase 1 SA negotiations are bidirectional, which means that data can be sent and received
using the same encryption key. Even if the SA negotiation data stream between the two IPsec
peers is compromised, there is little chance that the encryption keys could be decrypted.
The three exchanges of IKE Phase 1 transpire in what is called main mode. The outcome of main
mode is a secure communication path for subsequent exchanges between the peers.
IKE Phase 1 can also transpire in aggressive mode. Aggressive mode is faster than main mode be-
cause there are fewer exchanges. Aggressive mode compresses the IKE SA negotiation phases into
one exchange with three packets. Main mode requires three exchanges with six packets.
Aggressive mode packets include:

First packet - The initiator packages everything needed for the SA negotiation in the first

message, including its DH public key.
Second packet - The recipient responds with the acceptable parameters, authentication

information, and its DH public key.
Third packet - The initiator then sends a confirmation that it received that information.

242 CCNA Security Course Booklet, Version 1.0

Aggressive mode negotiation is quicker, and the initiator and responder IDs pass in plaintext.
After the IKE SA is established, Phase 2 negotiation begins.
The purpose of IKE Phase 2 is to negotiate the IPsec security parameters that will be used to se-
cure the IPsec tunnel. IKE Phase 2 is called quick mode and can only occur after IKE has estab-
lished the secure tunnel in Phase 1. SAs are negotiated by the IKE process ISAKMP on behalf of
IPsec, which needs encryption keys for operation. Quick mode negotiates the IKE Phase 2 SAs. In
this phase, the SAs that IPsec uses are unidirectional; therefore, a separate key exchange is re-
quired for each data flow.
IKE Phase 2 performs the following functions:

Negotiates IPsec security parameters, known as IPsec transform sets

Establishes IPsec SAs

Periodically renegotiates IPsec SAs to ensure security

Optionally performs an additional DH exchange

Quick mode also renegotiates a new IPsec SA when the IPsec SA lifetime expires. Basically, quick
mode refreshes the keying material that creates the shared secret key based on the keying material
that is derived from the DH exchange in Phase 1.

8.4 Implementing Site-to-Site IPsec VPNs with
8.4.1 Configuring a Site-to-Site IPsec VPN
A VPN is a communications channel that is used to form a logical connection between two end-
points over a public network. VPNs do not necessarily include encryption or authentication. IPsec
VPNs rely on the IKE protocol to establish secure communications.
IPsec VPN negotiation involves several steps, which include Phase 1 and Phase 2 of IKE negotia-

An IPsec tunnel is initiated when host A sends “interesting” traffic to host B.
1. Step 1.
Traffic is considered interesting when it travels between the IPsec peers and meets the criteria
that is defined in the crypto access control list (ACL).
IKE Phase 1 begins. The IPsec peers negotiate the established IKE security
2. Step 2.
association (SA) policy. When the peers are authenticated, a secure tunnel is created using
Internet Security Association and Key Management Protocol (ISAKMP).
IKE Phase 2 begins. The IPsec peers use the authenticated secure tunnel to
3. Step 3.
negotiate IPsec SA transforms. The negotiation of the shared policy determines how the IPsec
tunnel is established.
The IPsec tunnel is created and data is transferred between the IPsec peers based
4. Step 4.
on the IPsec parameters that are configured in the IPsec transform sets.
The IPsec tunnel terminates when the IPsec SAs are deleted or when their
5. Step 5.
lifetime expires.

Some basic tasks must be completed to configure a site-to-site IPsec VPN.
Chapter 8: Implementing Virtual Private Networks 243

Task 1. Ensure that ACLs configured on the Interface are compatible with IPsec configuration.
Usually there are restrictions on the interface that the VPN traffic uses; for example, block all traf-
fic that is not IPsec or IKE.
Task 2. Create an ISAKMP policy to determine the ISAKMP parameters that will be used to es-
tablish the tunnel.
Task 3. Define the IPsec transform set. The definition of the transform set defines the parameters
that the IPsec tunnel uses. The set can include the encryption and integrity algorithms.
Task 4. Create a crypto ACL. The crypto ACL defines which traffic is sent through the IPsec tun-
nel and protected by the IPsec process.
Task 5. Create and apply a crypto map. The crypto map groups the previously configured parame-
ters together and defines the IPsec peer devices. The crypto map is applied to the outgoing inter-
face of the VPN device.

8.4.2 Task 1 - Configure Compatible ACLs
The first step in configuring Cisco IOS ISAKMP is to ensure that the existing ACLs on perimeter
routers, firewalls, or other routers do not block IPsec traffic. Perimeter routers typically implement
a restrictive security policy with ACLs, where only specific traffic is permitted, and all other traffic
is denied. Such a restrictive policy blocks IPsec traffic. Therefore, specific permit statements must
be added to the ACL.
Ensure that the ACLs are configured so that ISAKMP, Encapsulating Security Payload (ESP), and
Authentication Header (AH) traffic is not blocked at the interfaces used by IPsec.

ESP is assigned IP protocol number 50.

AH is assigned IP protocol number 51.

ISAKMP uses UDP port 500.

To permit AH, ESP, and ISAKMP on an IPsec interface while denying any other unnecessary traf-
fic, an existing ACL must be edited or a new ACL created.

To permit AH traffic, use the access-list acl permit
– ahp source wildcard destination
wildcard command.

To permit ESP traffic, use the access-list acl permit
– esp source wildcard destination
wildcard command.

To permit ISAKMP traffic, use the access-list acl permit
– udp source wildcard
destination wildcard eq isakmp command.

Use the show command to verify the entries.

8.4.3 Task 2 - Configure IKE
The second major task in configuring Cisco IOS ISAKMP support is to define the parameters
within the IKE policy. IKE uses these parameters during negotiation to establish ISAKMP peering
between two IPsec endpoints.
Multiple ISAKMP policies can be configured on each peer participating in IPsec. When configur-
ing policies, each policy must be given a unique priority number. Use the command crypto
244 CCNA Security Course Booklet, Version 1.0

where the priority is a number that uniquely identifies the IKE policy
isakmp policy priority,
and assigns a priority to the policy. Use an integer from 1 to 10,000, with 1 being the highest prior-
ity and 10,000 the lowest. Assign the most secure policy the smallest available number.
The crypto isakmp policy command invokes ISAKMP policy configuration command mode.
Set the ISAKMP parameters in this mode. If commands are not explicitly configured, default val-
ues are used. For example, if the hash command is not explicitly configured, IKE uses the default
SHA value.
Two endpoints must negotiate ISAKMP policies before they agree on the SA to use for IPsec.
When the ISAKMP negotiation begins in IKE Phase 1 main mode, the peer that initiates the nego-
tiation sends all its policies to the remote peer, and the remote peer tries to find a match with its
own policies. The remote peer looks for a match by comparing its own highest priority policy
against the policies it received from the other peer. The remote peer checks each of its policies in
order of its priority (highest priority first) until a match is found.
A match is made when both policies from the two peers contain the same encryption, hash, au-
thentication, DH parameter values, and when the policy of the remote peer specifies a lifetime less
than or equal to the lifetime of the policy that is being compared. If the lifetimes are not identical,
the shorter lifetime from the remote peer policy is used. Assign the most secure policy the smallest
available priority number so that the most secure policy finds a match before any less secure poli-
cies are configured.
If an acceptable match is not found, ISAKMP refuses negotiation, and IPsec is not established. If a
match is found, ISAKMP completes the main mode negotiation, and IPsec SAs are created during
IKE Phase 2 quick mode.
PSKs are required for encryption. At a given peer, the same key can be configured to be shared
with multiple remote peers. A more secure approach is to specify different keys to share between
different pairs of peers.
Configure a PSK with the crypto isakmp key global configuration command. This key must be
configured if the authentication pre-share command was configured in the ISAKMP policy.
crypto isakmp key keystring address peer-address


. 10
( 19)