Вы находитесь на странице: 1из 136

IPsec VPNs

2006 Cisco Systems, Inc. All rights reserved.

BCMSN v3.02-1

3.1 Introducing VPN Technology


3.1.1 What Is Needed to Build a VPN?
A virtual private network (VPN) is a concept that describes how to create a
private network over a public network infrastructure while maintaining
confidentiality and security.
VPNs can be implemented at Layers 2, 3, and 4 of the Open Systems
Interconnection (OSI) model.

2006 Cisco Systems, Inc. All rights reserved.

BCMSN v3.02-2

2006 Cisco Systems, Inc. All rights reserved.

BCMSN v3.02-3

Figure illustrates a typical VPN topology.


Components required to establish a VPN include:
An existing network with servers and workstations
Connection to the Internet
VPN gateways (i.e., routers, PIX, ASA, VPN concentrators) that act as
endpoints to establish, manage, and control VPN connections
Software to create and manage tunnels
The key to VPN technology is security. VPNs secure data by encapsulating
the data, encrypting the data, or both encapsulating the data and then
encrypting it.

2006 Cisco Systems, Inc. All rights reserved.

BCMSN v3.02-4

3.1.2 Overlay and Peer-to-Peer VPN Architecture


In terms of evolution, there are two major VPN models: overlay VPN and
peer-to-peer VPN.
Overlay VPNs
The overlay model includes L2 and L3 VPNs.
L2 overlay VPN: L2 overlay VPNs are independent of the network protocol used
by the customer meaning that the VPN is not limited to carrying IP traffic-Frame
Relay VPNs .
L3 overlay VPN: L3 Overlay VPNs most often use an IP in IP tunneling scheme
using Point to Point Tunneling Protocol (PPTP), Layer 2 Tunneling Protocol
(L2TP), and IP security (IPsec).

2006 Cisco Systems, Inc. All rights reserved.

BCMSN v3.02-5

CPE-Based VPN (Peer-to-Peer)


CPE-based VPN is another name for an L3 overlay VPN. The VPN is
implemented using CPE. In this way, a customer creates a VPN across an
Internet connection without any specific knowledge or cooperation from the
service provider.
SP-Provisioned VPN
MPLS VPN

2006 Cisco Systems, Inc. All rights reserved.

BCMSN v3.02-6

2006 Cisco Systems, Inc. All rights reserved.

BCMSN v3.02-7

2006 Cisco Systems, Inc. All rights reserved.

BCMSN v3.02-8

3.1.3 VPN Topologies


There are three VPN topologies to consider:
Remote Access VPN : Tunnels are created using either IPsec, Point to Point
Tunneling Protocol (PPTP), Layer 2 Tunnel Protocol (L2TP), or Layer 2 Forwarding
(L2F) Protocol. Benefits: Remote access VPNs reduce long-distance charges that are
associated with dialup access.
Site-to-Site Intranet VPN : Site-to-site intranet VPNs link headquarters, remote
offices, and branch offices to an internal network over a shared infrastructure using
dedicated connections.
Site-to-Site Extranet VPN : An extranet site-to-site VPN links outside customers,
suppliers, partners, or communities of interest to an enterprise customer's network
over a shared infrastructure using dedicated connections

2006 Cisco Systems, Inc. All rights reserved.

BCMSN v3.02-9

2006 Cisco Systems, Inc. All rights reserved.

BCMSN v3.02-10

2006 Cisco Systems, Inc. All rights reserved.

BCMSN v3.02-11

2006 Cisco Systems, Inc. All rights reserved.

BCMSN v3.02-12

3.1.4 Characteristics of a Secure VPNs


By properly implementing security, successful VPN implementations
meet three goals:

Authentication: Authentication ensures that a message comes from an

authentic source and goes to an authentic destination. VPN technologies are


making use of several reputable methods for establishing the identity of the
party at the other end of a network. These include passwords, digital
certificates, smart cards, and biometrics.

Data confidentiality: As a design feature, data confidentiality aims at

protecting the message contents from being intercepted by unauthenticated


or unauthorized sources. VPNs achieve confidentiality using mechanisms of
encapsulation and encryption.

Data integrity: Since you have no control over where the data has

traveled and who has seen or handled the data you send or receive while the
data journeys across the Internet, there is always the possibility that the
data has been modified. Data integrity guarantees that no tampering or
alterations occur to data while it travels between the source and destination.
VPNs typically use one of three technologies to ensure data integrity: oneway hash functions, message authentication codes (MAC), or digital
signatures.

2006 Cisco Systems, Inc. All rights reserved.

BCMSN v3.02-13

3.1.5 VPN Security: Encapsulation


Tunneling is the process of placing an entire packet within another packet
and sending the new, composite packet over a network.

2006 Cisco Systems, Inc. All rights reserved.

BCMSN v3.02-14

The three different protocols that tunneling uses are:


Carrier protocol: The protocol the information is traveling over (Frame Relay,
ATM, MPLS)
Encapsulating protocol: The protocol (GRE, IPsec, L2F, PPTP, L2TP) that is
wrapped around the original data.
Passenger protocol: The original data (IPX, AppleTalk, IPv4, IPv6).

2006 Cisco Systems, Inc. All rights reserved.

BCMSN v3.02-15

2006 Cisco Systems, Inc. All rights reserved.

BCMSN v3.02-16

3.1.6 VPN Security: IPsec and GRE


Use IPsec in conjunction with GRE when support for IP multicast,
dynamic IGP routing protocols, or non-IP protocols is required.
IPsec has two encryption modes:
Tunnel mode
Transport mode

Tunnel mode encrypts the header and the payload of each packet while
transport mode only encrypts the payload.

2006 Cisco Systems, Inc. All rights reserved.

BCMSN v3.02-17

2006 Cisco Systems, Inc. All rights reserved.

BCMSN v3.02-18

3.1.7 VPN Security: Symmetric and Asymmetric


Encryption Algorithms
Encryption is the process of taking all the data that one computer is
sending to another computer and encoding the data into a form that only
the intended destination computer will be able to decode.
Symmetric-key encryption: Symmetric-key encryption, also called secret key
encryption, works when each computer has a secret key (code) that the
computer uses to encrypt information before the information is sent over the
network to another computer.
Asymmetric Encryption: One key encrypts the message, while a second key
decrypts the message. It is not possible to encrypt and decrypt with the same
key. Public-key encryption uses a combination of a private key and a public key.
Only the sender knows the private key. The sender gives a public key to any
recipient that the sender with whom he wants to communicate. To decode an
encrypted message, the recipient must use the public key, provided by the
originating sender, and the recipients own private key.

2006 Cisco Systems, Inc. All rights reserved.

BCMSN v3.02-19

2006 Cisco Systems, Inc. All rights reserved.

BCMSN v3.02-20

2006 Cisco Systems, Inc. All rights reserved.

BCMSN v3.02-21

3.1.8 Symmetric Encryption Algorithms


Symmetric-key algorithms can be divided into:
stream ciphers
block ciphers.

Stream ciphers encrypt the bits of the message one at a time, and block
ciphers take a number of bits and encrypt them as a single unit.
A block cipher operates on fixed-length groups of bits, termed blocks,
with an unvarying transformation. When encrypting, a block cipher might
take, for example, a 128-bit block of plaintext as input, and output a
corresponding 128-bit block of ciphertext.
Decryption is similar: the decryption algorithm takes, in this example, a
128-bit block of ciphertext together with the secret key, and yields the
original 128-bit block of plaintext.

2006 Cisco Systems, Inc. All rights reserved.

BCMSN v3.02-22

Symmetric Encryption: DES


DES is a block cipher encryption algorithm.
Given that you have 64 bits, you have 2^64 possible combinations.

2006 Cisco Systems, Inc. All rights reserved.

BCMSN v3.02-23

The key ostensibly consists of 64 bits; however, only 56 of these are


actually used by the algorithm.
Eight bits are used solely for checking parity, and are thereafter
discarded.
DES keys have been broken in less than 24 hours.

2006 Cisco Systems, Inc. All rights reserved.

BCMSN v3.02-24

Symmetric Encryption: 3DES

3DES is defined as performing a DES encryption, then a DES


decryption, and then a DES encryption again.
3DES has a key length of 168 bits (three 56-bit DES keys), its effective
key length from a security point of view is only 112 bits.

2006 Cisco Systems, Inc. All rights reserved.

BCMSN v3.02-25

Symmetric Encryption: AES


AES,is a block cipher that was adopted as an encryption standard by
the U.S. government.
AES has a fixed block size of 128 bits and a key size of 128, 192, or 256
bits.

2006 Cisco Systems, Inc. All rights reserved.

BCMSN v3.02-26

2006 Cisco Systems, Inc. All rights reserved.

BCMSN v3.02-27

3.1.9 Asymetric Encryption


Two asymmetric algorithms used for Ipsec:
Diffie-Hellman (DH)
RSA

RSA authenticates the remote device while Diffie-Hellman exchanges keys


that are used for encryption .

2006 Cisco Systems, Inc. All rights reserved.

BCMSN v3.02-28

The security of the RSA cryptosystem is based on


two mathematical problems: the problem of factoring
very large numbers and the RSA algorithm itself.

2006 Cisco Systems, Inc. All rights reserved.

BCMSN v3.02-29

The question is, how do the encrypting and decrypting devices


both have the shared secret key?
More secure method is DH public key exchange. The DH key
agreement is a public key encryption method that provides a
way for two peers to establish a shared secret key that only the
peers know, even though the peers are communicating over an
insecure channel.
Public key cryptosystems rely on a two-key system:
Public key: Exchanged between end users
Private key: Kept secret by the original owners

2006 Cisco Systems, Inc. All rights reserved.

BCMSN v3.02-30

3.1.10 Diffie-Hellman Key Exchange


With Diffie-Hellman, each peer generates a public and private key pair.
The private key that is generated by each peer is kept secret and never
shared. The public key is calculated from the private key by each peer and
is exchanged over the insecure channel.
Each peer combines the public key of the other peer with its own private
key and computes the same shared secret number. The shared secret
number is then converted into a shared secret key.

2006 Cisco Systems, Inc. All rights reserved.

BCMSN v3.02-31

Classic DH ExampleAlice and Bob


They can to this even when an eavesdropper (Eve) listens in on their
entire conversation.

2006 Cisco Systems, Inc. All rights reserved.

BCMSN v3.02-32

Step 1
First, Alice and Bob need to agree on a prime number p, which they can do
by simply sending it to each other. In this case, the agreed prime number p =
23.

Step 2
Given a prime number p, it is possible to come up with a number g (the socalled generator) with a very interesting property. Every number between 1
and p-1 can be written as a power of g when calculating modulo p. For now,
please accept that g = 2.

2006 Cisco Systems, Inc. All rights reserved.

BCMSN v3.02-33

For example, using p = 5 the generator is 2, because:


2^0 = 1
2^1 = 2
2^2 = 4
2^3 = 3 (because 8 = 3 mod 5)
Alice and Bob agree in the same way on a generator g for the numbers
between 1 and p-1.
At this point, the numbers p and g serve as the public key.

2006 Cisco Systems, Inc. All rights reserved.

BCMSN v3.02-34

Step 3
Alice and Bob both choose random numbers, a and b respectively.
Both these numbers remain secret because only Alice knows her number and
only Bob knows his number. In the example, Alice chose a = 6 and Bob chose
b = 16.
Step 4
Alice then computes (g^a mod p) and Bob computes (g^b mod p). They
exchange their results.

2006 Cisco Systems, Inc. All rights reserved.

BCMSN v3.02-35

Step 5
The key that Alice and Bob now agree on is simply g^(a*b). This is quite
easy to compute:
Alice knows a and g^b,
Bob knows b and g^a

and

(g^a)^b = (g^b)a = g^(a*b)

2006 Cisco Systems, Inc. All rights reserved.

BCMSN v3.02-36

Step 6
Alice and Bob can use the key g^(a*b) to encrypt messages with any secret
key algorithm.
The security of the Diffie-Hellman system depends on the assumption that it
is easy to raise a number to a certain power, but difficult to compute which
power was used given the number and the outcome.
For example, it's easy to compute 2^10 = 1024, but more difficult to
determine that 1024 is the tenth power of 2.

2006 Cisco Systems, Inc. All rights reserved.

BCMSN v3.02-37

2006 Cisco Systems, Inc. All rights reserved.

BCMSN v3.02-38

3.1.11 Data Integrity


Data integrity guarantees that no tampering or alterations occur
with data between the datas source and destination.
VPNs typically use one of three technologies to ensure integrity:
One-way hash functions: A hash function generates a fixed-length
output value based on an arbitrary-length input file. The idea is that it
is easy to calculate the hash value of a file but mathematically
difficult to generate a file that will hash to that value. Examples of
hash algorithms are MD5, Secure Hash Algorithm 1 (SHA-1),
Message-authentication codes (MACs): MACs add a key to hash
functions. A sender creates a file, calculates a MAC based on a key
shared with the recipient, and then appends the MAC to the file.
When the recipient receives the file, the receiver calculates a new
MAC and compares it with the appended MAC.
Digital signatures: A digital signature is essentially public key
cryptography in reverse. A sender digitally "signs" a document with
the senders private key and the recipient can verify the signature by
using the sender's public key.

2006 Cisco Systems, Inc. All rights reserved.

BCMSN v3.02-39

3.1.12VPN Security: Authentication


The following are methods used between two peers to establish that
they are each connecting to the right person and not to someone
pretending to be that peer:
Username and password: Uses the predefined usernames and passwords for
different users or systems.
One Time Password (OTP) (Pin/Tan): A stronger authentication method than
username and password, this method uses new passwords that are generated
for each authentication.
Biometric: Biometrics usually refers to technologies that are used for measuring
and analyzing human body characteristics such as fingerprints, eye retinas.
Pre-shared keys: This method uses a secret key value, manually entered into
each peer, and then used to authenticate the peers.
Digital certificates: Use the exchange of digital certificates to authenticate the
peers.

2006 Cisco Systems, Inc. All rights reserved.

BCMSN v3.02-40

3.2 Understanding IPsec Components and IPsec


VPN Features
3.2.1 IPsec Security Features
IPsec provides a mechanism for secure data transmission over
IP networks, ensuring confidentiality, integrity, and authenticity
of data communications over unprotected networks such as the
Internet .
IPsec provides the following essential security functions:
Data confidentiality: IPsec ensures confidentiality by using encryption.
Encryption is provided using encryption algorithms including DES, 3DES,
and AES.
Data integrity: IPsec ensures that data arrives unchanged at the
destination; that is, that the data is not manipulated at any point along the
communication path.. Data integrity is provided through the Hash-based
Message Authentication Code (HMAC) function. Supported HMAC
functions include Message Digest 5 (MD5) and Secure Hash Algorithm 1
(SHA-1).
2006 Cisco Systems, Inc. All rights reserved.

BCMSN v3.02-41

Data origin authentication: Authentication ensures that the connection


is actually made with the desired communication partner. IPsec
authenticates users (people) and devices that can carry out
communication independently. The quality of Data origin authentication is
dependent on the data integrity service that is provided.
Anti-replay: Anti-replay protection verifies that each packet is unique, not
duplicated.

2006 Cisco Systems, Inc. All rights reserved.

BCMSN v3.02-42

3.2.2 IPsec Protocols and Headers


IPsec includes a protocol for exchanging keys called Internet Key
Exchange (IKE) and two IPsec IP protocols, Encapsulating Security
Payload (ESP) and Authentication Header (AH).

2006 Cisco Systems, Inc. All rights reserved.

BCMSN v3.02-43

IPsec uses three main protocols to create a security framework:


IKE: Provides a framework for the negotiation of security parameters and
establishes authenticated keys. IPsec uses symmetrical encryption
algorithms for data protection,
AH: The IP Authentication Header (AH) provides connectionless integrity
and data origin authentication for IP datagrams and optional protection
against replays. AH is embedded in the data that needs to be protected.
ESP has replaced the AH protocol, and AH is no longer used very often in
IPsec.
ESP: Encapsulating Security Payload (ESP) provides a framework for
encrypting, authenticating, and securing data. ESP provides data privacy
services, optional data authentication, and anti-replay services. ESP
encapsulates the data that needs protection. Most IPsec implementations
use the ESP protocol.

2006 Cisco Systems, Inc. All rights reserved.

BCMSN v3.02-44

The AH provides authentication and integrity checks on the IP


datagram. Successful authentication means that the packet was,
indeed, sent by the apparent sender. Integrity means the packet was
not changed during transport.
The ESP header provides information that indicates encryption of the
datagram payload contents. The ESP header also provides
authentication and integrity checks.

2006 Cisco Systems, Inc. All rights reserved.

BCMSN v3.02-45

AH and ESP provide services to transport layer protocols such as TCP and
User Datagram Protocol (UDP).
AH and ESP are Internet protocols and are assigned numbers 51 (AH) and
50 (ESP) by the Internet Assigned Numbers Authority (IANA).
IPsec has a choice of different encryptions (Data Encryption Standard
[DES], Triple Data Encryption Standard [3DES], and Advanced Encryption
Standard [AES]) so that users can choose the strength of their data
protection.
IPsec also has several hash methods to choose from (Hash-based Message
Authentication Code [HMAC], Message Digest 5 [MD5], and Secure Hash
Algorithm 1 [SHA-1]), each giving different levels of protection.

2006 Cisco Systems, Inc. All rights reserved.

BCMSN v3.02-46

2006 Cisco Systems, Inc. All rights reserved.

BCMSN v3.02-47

3.2.3 Internet Key Exchange


IKE includes these features:
Eliminates the need to manually specify all of the IPsec
security parameters at both peers
Allows specification for a lifetime for the IPsec SA
Allows encryption keys to change during IPsec sessions
Allows IPsec to provide anti-replay services
Permits certification authority (CA) support for a
manageable, scalable IPsec implementation
Allows dynamic authentication of peers

2006 Cisco Systems, Inc. All rights reserved.

BCMSN v3.02-48

3.2.4 IKE Phases and Modes


IKE is executed in two phases to establish a secure communication
channel between two peers:
IKE Phase 1: Phase 1 is the initial negotiation of SAs between two IPsec peers.
Optionally, Phase 1 can also include an authentication in which each peer is able to
verify the identity of the other. Phase 1 SAs are bidirectional; data can be sent and
received using the same key material that is generated. IKE Phase 1 occurs in two
modes: main mode or aggressive mode.
IKE Phase 1.5 (optional): To further authenticate VPN participants (clients), you can
use a protocol called Extended Authentication (Xauth) that provides user
authentication of IPsec tunnels within the IKE protocol. Additionally, you can exchange
other parameters between the peers. Mode configuration is used to deliver parameters
such as the IP address and Domain Name System (DNS) address to the client.
IKE Phase 2: Because the SAs that are used by IPsec are unidirectional, separate key
exchanges are needed for data that is flowing in the forward direction and the reverse
direction. The two peers have already agreed upon the transform sets, hash methods,
and other parameters during the Phase 1 negotiation. Quick mode is the method used
for the Phase 2 SA negotiations.

2006 Cisco Systems, Inc. All rights reserved.

BCMSN v3.02-49

To establish a secure communication channel between two peers, the IKE


protocol uses these three modes of operation:
Main Mode: In the main mode, an IKE session begins with the initiator sending a
proposals to the responder. These proposals define which encryption and
authentication protocols are acceptable, how long keys should remain active, and
whether perfect forward secrecy (PFS) should be enforced. The next exchange
passes DH public keys and other data. All further negotiation is encrypted within
the IKE SA. The third exchange authenticates the ISAKMP session.
Aggressive Mode: The aggressive mode squeezes the IKE SA negotiation into
three packets. Negotiation is quicker than in main mode, and the initiator and
responder ID pass in plaintext.
Quick Mode: The quick mode IPsec negotiation is similar to an aggressive mode
IKE negotiation, except negotiation must be protected within an IKE SA. Quick
mode negotiates the SA for the data encryption and manages the key exchange
for that IPsec SA.

2006 Cisco Systems, Inc. All rights reserved.

BCMSN v3.02-50

2006 Cisco Systems, Inc. All rights reserved.

BCMSN v3.02-51

3.2.5 Other IKE Functions

Dead Peer Detection (DPD) and Cisco IOS Keepalives


DPD and Cisco IOS keepalives function on the basis of a
timer. If the timer is set for 10 seconds, the router will
send a hello message every 10 seconds.

2006 Cisco Systems, Inc. All rights reserved.

BCMSN v3.02-52

The Problem with NAT


.
The Solution: IPsec NAT Transversal (NAT-T)
The IPsec NAT-T, which was introduced in Cisco IOS Release 12.2(13)T,
enables IPsec traffic to travel through NAT or PAT devices in the
network by encapsulating IPsec packets in a UDP wrapper.

2006 Cisco Systems, Inc. All rights reserved.

BCMSN v3.02-53

NAT-T is negotiated with these factors:

NAT-T detection
During IKE Phase 1 negotiation, two types of NAT detection occur
before IKE quick mode begins: NAT support and NAT existence along
the network path. To detect NAT support, the vendor ID string is
exchanged with the remote peer.
NAT-T enables an IPsec device to find any NAT device between two
IPsec peers. To detect whether a NAT device exists along the network
path, the peers send a payload with hashes of the IP address and port
of both the source and destination address from each end. If the
payload hash and recalculated hashes do not match (that is, someone
translated the address or port), then each peer needs to perform NATT to transport the IPsec packet through the network.

2006 Cisco Systems, Inc. All rights reserved.

BCMSN v3.02-54

2006 Cisco Systems, Inc. All rights reserved.

BCMSN v3.02-55

3.2.6 ESP and AH Protocols, Transport, and Tunnel


Modes

2006 Cisco Systems, Inc. All rights reserved.

BCMSN v3.02-56

2006 Cisco Systems, Inc. All rights reserved.

BCMSN v3.02-57

2006 Cisco Systems, Inc. All rights reserved.

BCMSN v3.02-58

2006 Cisco Systems, Inc. All rights reserved.

BCMSN v3.02-59

3.2.9 Message Authentication and Integrity Check


VPN data can be transported over the public Internet. Potentially, this data could be
intercepted and modified. To guard against the chance of interception, each message has
a hash attached to the message.
A hash provides a way to guarantee the integrity of the original message: If the
transmitted hash matches the received hash, the message has not been tampered with.
However, if the hashes do not match, the message was altered.
The HMAC is used for message authentication and integrity check. HMAC can be used
with any iterative cryptographic hash function, such as MD5 or SHA-1, in combination
with a secret shared key.
MD5 is well known from various uses in Cisco components, such as hashing passwords
in the Cisco IOS software.
MD5 creates a 128-bit hash, while SHA-1 creates a 160-bit hash. In the case of SHA-1, only
96 bits of this hash are used for IPsec.
The initialization vector (IV) is used as an initial value to start creating a hash.

2006 Cisco Systems, Inc. All rights reserved.

BCMSN v3.02-60

3.2.10 PKI Environment


A PKI consists of these entities:
At least one certificate authority (CA) to grant and maintain
certificates
Digital certificates, which contain information such as the
certificate validity period, peer identity information,
encryption keys that are used for secure communications,
and the signature of the issuing CA
A distribution mechanism, such as Lightweight Directory
Access Protocol (LDAP) or HTTP, for certificate revocation
lists (CRLs)

2006 Cisco Systems, Inc. All rights reserved.

BCMSN v3.02-61

The structure of a X.509 v3 digital certificate is shown in :


Certificate

Version
Serial Number
Algorithm ID
Issuer
Validity:
Not before
Not after
Subject Public Key Info
Public Key Algorithm
Subject Public Key
Certificate Signature Algorithm
Certificate Signature

2006 Cisco Systems, Inc. All rights reserved.

BCMSN v3.02-62

PKI Message Exchange


Step 1
The end host generates an RSA key pair and requests the public key of
the CA.
Step 2
The CA sends the CA public key to the end host

2006 Cisco Systems, Inc. All rights reserved.

BCMSN v3.02-63

Step 3
The end host generates a certificate request and forwards the request to the
CA
Step 4
After the request is approved, the CA signs the request with the CAs private
key.
Step 5
The CA returns the completed certificate to the end host. The end host writes
the certificate to a storage area such as NVRAM.
Step 6
The end host uses the certificate for communication with other
communication partners.

2006 Cisco Systems, Inc. All rights reserved.

BCMSN v3.02-64

2006 Cisco Systems, Inc. All rights reserved.

BCMSN v3.02-65

2006 Cisco Systems, Inc. All rights reserved.

BCMSN v3.02-66

3.3 Implementing Site-to-Site IPsec VPN


Operations
3.3.1 Site-to-Site IPsec VPN Operations

2006 Cisco Systems, Inc. All rights reserved.

BCMSN v3.02-67

2006 Cisco Systems, Inc. All rights reserved.

BCMSN v3.02-68

3.3.2 Step 2: IKE Phase 1


The purpose of IKE Phase 1 is to negotiate IKE policy sets, authenticate the peers,
and set up a secure channel between the peers.
IKE Phase 1 occurs in two modes:
main mode
aggressive mode

The main mode has three two-way exchanges between the initiator and receiver:
First exchange: The two peers negotiate and agree on which algorithms and hashes to use to
secure the IKE communications.
Second exchange: A Diffie-Hellmann exchange generates shared secret keys and pass nonces (a
nonce is a value used only once by a computer security system). A random number sent by one
party to another party, signed, and returned to the first party proves the second partys identity.
Once created, the shared secret key is used to generate all the other encryption and authentication
keys.
Third exchange: In this exchange, each peer verifies the identity of the other side by authenticating
the remote peer.

2006 Cisco Systems, Inc. All rights reserved.

BCMSN v3.02-69

In aggressive mode, fewer exchanges take place with


fewer packets.

2006 Cisco Systems, Inc. All rights reserved.

BCMSN v3.02-70

Matching IKE Policies


When a secure connection is being made between Host A and Host B
through the Internet, IKE security proposals are exchanged between
Router A and Router B.
The proposals identify the IPsec protocol that is being negotiated (for
example, Encapsulating Security Payload [ESP]). Under each proposal,
the originator must delineate which algorithms are used in the
proposal (for example, Data Encryption Standard [DES] with Message
Digest 5 [MD5]).

2006 Cisco Systems, Inc. All rights reserved.

BCMSN v3.02-71

After the group negotiations are completed, the shared secret key is
calculated.
The shared secret key, SKEYID, is used in the derivation of three other keys:
SKEYID_a, SKEYID_e, and SKEYID_d.
Each key has a separate purpose:
SKEYID_a is the keying material that is used during the authentication
process
SKEYID_e key is the keying material that is used in the encryption process
SKEY_d key is the keying material that is used to derive keys for nonInternet Security Association and Key Management Protocol (non-ISAKMP)
SAs

2006 Cisco Systems, Inc. All rights reserved.

BCMSN v3.02-72

The last exchange of IKE Phase 1 authenticates the remote peer. There
are three methods for identifying data origin:
Pre-shared keys: A secret key value is entered into each peer manually
and used to authenticate the peers.
RSA signatures: Digital certificates are exchanged to authenticate the
peers.
RSA encrypted nonces: Nonces are encrypted and then exchanged
between peers. The two nonces are used during a peer authentication
process.

2006 Cisco Systems, Inc. All rights reserved.

BCMSN v3.02-73

2006 Cisco Systems, Inc. All rights reserved.

BCMSN v3.02-74

2006 Cisco Systems, Inc. All rights reserved.

BCMSN v3.02-75

2006 Cisco Systems, Inc. All rights reserved.

BCMSN v3.02-76

2006 Cisco Systems, Inc. All rights reserved.

BCMSN v3.02-77

3.3.3 Step 3: IKE Phase 2


IKE Phase 2 performs these functions:
Negotiates IPsec security parameters and IPsec transform
sets
Establishes IPsec SAs
Periodically renegotiates IPsec SAs to ensure security
Optionally, performs an additional Diffie-Hellmann exchange

IKE Phase 2 has one mode called quick mode. Quick


mode occurs after IKE has established the secure
tunnel in Phase 1.

2006 Cisco Systems, Inc. All rights reserved.

BCMSN v3.02-78

IPsec Transform Sets


Each pair of endpoints negotiates the level of
security that is required (for example, encryption and
authentication algorithms for the session).

2006 Cisco Systems, Inc. All rights reserved.

BCMSN v3.02-79

Security Associations
When two peers agree on which security services they will use, each VPN peer
device enters the information in a Security Policy Database (SPD). The
information in the SPD includes the encryption and authentication algorithm,
destination IP address, transport mode, key lifetime, and any other security
information. This information is referred to as the SA. An SA is a one-way logical
connection that provides security to all traffic that is traversing the connection.
Because most traffic is bidirectional, two SAs are required: one for inbound
traffic and one for outbound traffic.
The VPN device indexes the SA with a number called a Security Parameter Index
(SPI). Rather than send the individual parameters of the SA across the tunnel,
the source gateway, or host, inserts the SPI into the ESP header.

2006 Cisco Systems, Inc. All rights reserved.

BCMSN v3.02-80

2006 Cisco Systems, Inc. All rights reserved.

BCMSN v3.02-81

2006 Cisco Systems, Inc. All rights reserved.

BCMSN v3.02-82

2006 Cisco Systems, Inc. All rights reserved.

BCMSN v3.02-83

3.3.5 Configuring a Site-to-Site IPsec VPN

2006 Cisco Systems, Inc. All rights reserved.

BCMSN v3.02-84

2006 Cisco Systems, Inc. All rights reserved.

BCMSN v3.02-85

2006 Cisco Systems, Inc. All rights reserved.

BCMSN v3.02-86

2006 Cisco Systems, Inc. All rights reserved.

BCMSN v3.02-87

2006 Cisco Systems, Inc. All rights reserved.

BCMSN v3.02-88

2006 Cisco Systems, Inc. All rights reserved.

BCMSN v3.02-89

2006 Cisco Systems, Inc. All rights reserved.

BCMSN v3.02-90

2006 Cisco Systems, Inc. All rights reserved.

BCMSN v3.02-91

2006 Cisco Systems, Inc. All rights reserved.

BCMSN v3.02-92

2006 Cisco Systems, Inc. All rights reserved.

BCMSN v3.02-93

2006 Cisco Systems, Inc. All rights reserved.

BCMSN v3.02-94

3.5 Configuring GRE Tunnels over IPsec


3.5.1Generic Routing Encapsulation
Routing protocols that are used across the tunnel enable dynamic
exchange or routing information in the virtual network.
Default GRE Characteristics
GRE uses a protocol type field in the GRE header to support the
encapsulation of any OSI Layer 3 protocol.
GRE tunnels are stateless. This characteristic means that each tunnel
endpoint does not keep any information about the state or availability
of the remote tunnel endpoint.

2006 Cisco Systems, Inc. All rights reserved.

BCMSN v3.02-95

Basic GRE Header


Figure shows a GRE tunnel header. A GRE tunnel header contains at least two 2-byte
mandatory fieldsthe GRE flag and the protocol type:
GRE flags: The GRE flags are encoded in the first two octets. Bit 0 is the most
significant bit, and bit 15 is the least significant bit. Some of the GRE flags include
the following:
Checksum Present (bit 0): If the Checksum Present bit is set to 1, the optional
checksum field is present in the GRE header.
Key Present (bit 2): If the Key Present bit is set to 1, the optional Key field is present in
the GRE header.
Sequence Number Present (bit 3): If the Sequence Number Present bit is set to 1, the
optional Sequence Number field is present in the GRE header.
Version Number (bits 1315): The Version Number indicates the GRE implementation
version. A value of 0 is typically used for basic GRE implementation. Point-to-Point
Tunneling Protocol (PPTP) uses Version 1.

2006 Cisco Systems, Inc. All rights reserved.

BCMSN v3.02-96

Protocol Type: The Protocol Type field contains the protocol type of the
payload packet. In general, the value will be the Ethernet protocol type
field for the packet. For IP, the hexadecimal value of 0x800 is used. This
field enables the GRE to tunnel any OSI Layer 3 protocol.

2006 Cisco Systems, Inc. All rights reserved.

BCMSN v3.02-97

Optional GRE Extensions


The GRE tunnel header can contain additional optional header information, depending
on the flags in the first two bytes of the GRE header.
Tunnel checksum: The tunnel checksum detects packet corruption. This option is not
used often because checksums are used on other layers in the protocol stack, typically to
ensure the accuracy of the GRE packets.
Tunnel key: Can be used for two purposes:
The tunnel key can be used for basic plaintext authentication of packets in
which only the two GRE endpoints share a secret number that enables the
tunnel to operate properly. However, anyone in the packet path can easily see
the key and be able to spoof tunnel packets.
A more common use of the tunnel key is when two routers want to establish
parallel tunnels sourced from the same IP address. The tunnel key is then used
to distinguish between GRE packets belonging to different tunnels.
Tunnel sequence number: This number is used to ensure that GRE packets are
accepted only if the packets arrive in the correct order.

2006 Cisco Systems, Inc. All rights reserved.

BCMSN v3.02-98

2006 Cisco Systems, Inc. All rights reserved.

BCMSN v3.02-99

2006 Cisco Systems, Inc. All rights reserved.

BCMSN v3.02-100

2006 Cisco Systems, Inc. All rights reserved.

BCMSN v3.02-101

2006 Cisco Systems, Inc. All rights reserved.

BCMSN v3.02-102

3.5.2 Secure GRE Tunnels?

2006 Cisco Systems, Inc. All rights reserved.

BCMSN v3.02-103

2006 Cisco Systems, Inc. All rights reserved.

BCMSN v3.02-104

2006 Cisco Systems, Inc. All rights reserved.

BCMSN v3.02-105

How DPD and Cisco IOS Keepalive


Features Work
Cisco IOS keepalives are always transmitted while periodic DPD will
only send keepalives when there is no traffic flowing.
The benefit of Cisco IOS keepalives and periodic DPD is earlier
detection of dead peers.

2006 Cisco Systems, Inc. All rights reserved.

BCMSN v3.02-106

3.6.2 IPsec Backup Peer


DPD and IOS keepalive features can be used in conjunction with
multiple peers in the crypto map to allow for stateless failover.
DPD allows the router to detect a dead IKE peer. When the router
detects the dead state, the router deletes the IPsec and IKE SAs to the
peer. If you configure multiple peers, the router switches over to the
next listed peer for a stateless failover.

2006 Cisco Systems, Inc. All rights reserved.

BCMSN v3.02-107

2006 Cisco Systems, Inc. All rights reserved.

BCMSN v3.02-108

3.6.4 HSRP for Default Gateway at Remote Site

2006 Cisco Systems, Inc. All rights reserved.

BCMSN v3.02-109

3.6.5 HSRP for Head-end IPsec Routers


Devices behind the head-end VPN routers can find the return path
toward remote sites using one of these two mechanisms:
HSRP on the inside interface, configured similarly to the HSRP on the
outside interface
Reverse Route Injection (RRI) to inject remote networks into an Interior
Gateway Protocol (IGP) and distribute it to other routers in the network

2006 Cisco Systems, Inc. All rights reserved.

BCMSN v3.02-110

2006 Cisco Systems, Inc. All rights reserved.

BCMSN v3.02-111

3.6.6 IPsec Stateful Failover


When IPsec is configured as stateless failover, then when there is a
failure, a tunnel will typically go down and have to be reestablished.
Stateful failover ensures that when there is a failure, any tunnel that
goes down is reestablished automatically without losing state.
When configuring redundancy for a VPN, these restrictions exist:
Both the active and standby devices must run the identical Cisco IOS
software release, and both the active and standby devices must be
connected to each other via a hub or switch.
Only the VPN Acceleration Module (VAM), VPN Acceleration Module 2 (VAM2),
and Advanced Integration Module (AIM)-VPN/HPII hardware encryption
accelerators are supported.
Only box-to-box failover is supported; that is, intra-chassis failover is
currently not supported.
HSRP requires inside interfaces and outside interfaces to be connected via
LANs.

2006 Cisco Systems, Inc. All rights reserved.

BCMSN v3.02-112

SSO allows the active and standby routers to share IKE and IPsec state
information so that each router has enough information to become the
active router at any time. To configure stateful failover for IPsec, you
should enable HSRP, assign a virtual IP address, and enable the SSO
protocol.

2006 Cisco Systems, Inc. All rights reserved.

BCMSN v3.02-113

IPsec Stateful Failover Example


In the figure, the
Roueter(config)#crypto map redundancy <name> stateful
is configured with the stateful keyword, which requires HSRP to be
configured in combination with SSO.
The right part of the configuration example shows how the HSRP
profile named VPNHA is configured to exchange IPsec state with the
other HSRP router using Stream Control Transmission Protocol (SCTP)
on source and destination port 12345.

2006 Cisco Systems, Inc. All rights reserved.

BCMSN v3.02-114

2006 Cisco Systems, Inc. All rights reserved.

BCMSN v3.02-115

2006 Cisco Systems, Inc. All rights reserved.

BCMSN v3.02-116

2006 Cisco Systems, Inc. All rights reserved.

BCMSN v3.02-117

3.6.7 Backing Up a WAN Connection with an IPsec


VPN

In order to operate an IGP across an IPsec tunnel, you should use GRE over
IPsec, which provides a virtual point-to-point link. Alternatively, you can use a
newer method in which virtual interfaces are used with native IPsec (no
additional GRE headers are used).
An alternative is to use native IPsec and configure floating static routes (that is,
routes that have high administrative distance and, optionally, that are locally
redistributed having a very high cost) for the VPN destination that points to the
Internet.

2006 Cisco Systems, Inc. All rights reserved.

BCMSN v3.02-118

2006 Cisco Systems, Inc. All rights reserved.

BCMSN v3.02-119

2006 Cisco Systems, Inc. All rights reserved.

BCMSN v3.02-120

3.7 Introducing Cisco Easy VPN


3.7.1Introducing Cisco Easy VPN
The Cisco Easy VPN Remote feature allows Cisco routers running
Cisco IOS Release 12.2(4)YA (or later releases), Cisco PIX firewalls, and
Cisco hardware clients to act as remote VPN clients.

2006 Cisco Systems, Inc. All rights reserved.

BCMSN v3.02-121

2006 Cisco Systems, Inc. All rights reserved.

BCMSN v3.02-122

3.7.2 Cisco Easy VPN Components


Cisco Easy VPN consists of two components as follows:
Cisco Easy VPN Server: Cisco Easy VPN Server enables Cisco IOS
routers, Cisco PIX Firewalls, and Cisco VPN 3000 Series Concentrators to
act as VPN headend devices in site-to-site or remote-access VPNs where
the remote office devices use the Cisco Easy VPN Remote feature.
Cisco Easy VPN Remote: Cisco Easy VPN Remote enables Cisco IOS
routers, Cisco PIX Firewalls, and Cisco VPN 3002 Hardware Clients or
Software Clients to act as remote VPN clients.

2006 Cisco Systems, Inc. All rights reserved.

BCMSN v3.02-123

3.7.5 Easy VPN Server and Easy VPN Remote


Operation
When an Easy VPN Remote client initiates a connection with a Cisco Easy
VPN Server gateway, the exchange that occurs between peers generally
consists of these steps:
Step 1
The VPN Client initiates the IKE Phase 1 process.
Step 2
The VPN Client establishes an ISAKMP SA.
Step 3
The Easy VPN Server accepts the SA proposal.
Step 4
The Easy VPN Server initiates a username and password challenge.

2006 Cisco Systems, Inc. All rights reserved.

BCMSN v3.02-124

Step 5
The mode configuration process is initiated.
Step 6
The Reverse Route Injection (RRI) process is
initiated.
Step 7
IPsec quick mode completes the connection.

2006 Cisco Systems, Inc. All rights reserved.

BCMSN v3.02-125

3.9 Implementing the Cisco VPN Client


3.9.1Cisco VPN Client Configuration Tasks

2006 Cisco Systems, Inc. All rights reserved.

BCMSN v3.02-126

3.9.2 Task 1: Install Cisco VPN Client

2006 Cisco Systems, Inc. All rights reserved.

BCMSN v3.02-127

3.9.3 Task 2: Create a New Client Connection Entry

2006 Cisco Systems, Inc. All rights reserved.

BCMSN v3.02-128

2006 Cisco Systems, Inc. All rights reserved.

BCMSN v3.02-129

2006 Cisco Systems, Inc. All rights reserved.

BCMSN v3.02-130

2006 Cisco Systems, Inc. All rights reserved.

BCMSN v3.02-131

3.9.4 Task 3: Configure Client Authentication


Properties

2006 Cisco Systems, Inc. All rights reserved.

BCMSN v3.02-132

3.9.6 Allowing Local LAN Access


The Allow Local LAN Access parameter gives you access to the
resources on your local LAN (printer, fax, shared files, or other
systems) when you are connected through a secure gateway to a
central-site VPN device.
When this parameter is enabled and your central site is configured to
permit access, you can access local resources while you are
connected. When this parameter is disabled, all traffic from your client
system goes through the IPsec connection to the secure gateway.

2006 Cisco Systems, Inc. All rights reserved.

BCMSN v3.02-133

2006 Cisco Systems, Inc. All rights reserved.

BCMSN v3.02-134

3.9.7 Task 5: Enable and Add Backup Servers

2006 Cisco Systems, Inc. All rights reserved.

BCMSN v3.02-135

3.9.8 Task 6: Configure Connection to the Internet


Through Dialup Networking

2006 Cisco Systems, Inc. All rights reserved.

BCMSN v3.02-136