IPsec VPNs

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.
BCMSN v3.02-2
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.
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).
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
BCMSN v3.02-6
BCMSN v3.02-7
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
BCMSN v3.02-9
BCMSN v3.02-10
BCMSN v3.02-11
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.
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.
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).
BCMSN v3.02-15
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.
BCMSN v3.02-17
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.
BCMSN v3.02-19
BCMSN v3.02-20
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.
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.
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.
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.
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.
BCMSN v3.02-26
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 .
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.
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
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.
BCMSN v3.02-31
Classic DH ExampleAlice and Bob

They can to this even when an eavesdropper (Eve) listens in on their
entire conversation.
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.
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.
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â mod p) and Bob computes (g^b mod p). They
exchange their results.
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â
and
(gâ)^b = (g^b)a = g^(a*b)
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.
BCMSN v3.02-37
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.
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.
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).
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.
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).
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.
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.
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.
BCMSN v3.02-46
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
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.
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.
BCMSN v3.02-50
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.
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.
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.
BCMSN v3.02-54
BCMSN v3.02-55
3.2.6 ESP and AH Protocols, Transport, and Tunnel

Modes
BCMSN v3.02-56
BCMSN v3.02-57
BCMSN v3.02-58
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.
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)
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
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
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.
BCMSN v3.02-64
BCMSN v3.02-65
BCMSN v3.02-66
3.3 Implementing Site-to-Site IPsec VPN

Operations
3.3.1 Site-to-Site IPsec VPN Operations
BCMSN v3.02-67
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.
BCMSN v3.02-69
In aggressive mode, fewer exchanges take place with

fewer packets.
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]).
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
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.
BCMSN v3.02-73
BCMSN v3.02-74
BCMSN v3.02-75
BCMSN v3.02-76
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.
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).
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.
BCMSN v3.02-80
BCMSN v3.02-81
BCMSN v3.02-82
BCMSN v3.02-83
3.3.5 Configuring a Site-to-Site IPsec VPN
BCMSN v3.02-84
BCMSN v3.02-85
BCMSN v3.02-86
BCMSN v3.02-87
BCMSN v3.02-88
BCMSN v3.02-89
BCMSN v3.02-90
BCMSN v3.02-91
BCMSN v3.02-92
BCMSN v3.02-93
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.
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.
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.
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.
BCMSN v3.02-98
BCMSN v3.02-99
BCMSN v3.02-100
BCMSN v3.02-101
BCMSN v3.02-102
3.5.2 Secure GRE Tunnels?
BCMSN v3.02-103
BCMSN v3.02-104
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.
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.
BCMSN v3.02-107
BCMSN v3.02-108
3.6.4 HSRP for Default Gateway at Remote Site
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
BCMSN v3.02-110
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.
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.
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.
BCMSN v3.02-114
BCMSN v3.02-115
BCMSN v3.02-116
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.
BCMSN v3.02-118
BCMSN v3.02-119
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.
BCMSN v3.02-121
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.
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.
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.
BCMSN v3.02-125
3.9 Implementing the Cisco VPN Client

3.9.1Cisco VPN Client Configuration Tasks
BCMSN v3.02-126
3.9.2 Task 1: Install Cisco VPN Client
BCMSN v3.02-127
3.9.3 Task 2: Create a New Client Connection Entry
BCMSN v3.02-128
BCMSN v3.02-129
BCMSN v3.02-130
BCMSN v3.02-131
3.9.4 Task 3: Configure Client Authentication

Properties
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.
BCMSN v3.02-133
BCMSN v3.02-134
3.9.7 Task 5: Enable and Add Backup Servers
BCMSN v3.02-135
3.9.8 Task 6: Configure Connection to the Internet

Through Dialup Networking
BCMSN v3.02-136

IPsec VPNs

Încărcat de

Informații document

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

IPsec VPNs

Încărcat de

Drepturi de autor:

Formate disponibile

IPsec VPNs

2006 Cisco Systems, Inc. All rights reserved.

3.1 Introducing VPN Technology

2006 Cisco Systems, Inc. All rights reserved.

2006 Cisco Systems, Inc. All rights reserved.

Figure illustrates a typical VPN topology.

2006 Cisco Systems, Inc. All rights reserved.

3.1.2 Overlay and Peer-to-Peer VPN Architecture

2006 Cisco Systems, Inc. All rights reserved.

CPE-Based VPN (Peer-to-Peer)

2006 Cisco Systems, Inc. All rights reserved.

2006 Cisco Systems, Inc. All rights reserved.

2006 Cisco Systems, Inc. All rights reserved.

3.1.3 VPN Topologies

2006 Cisco Systems, Inc. All rights reserved.

2006 Cisco Systems, Inc. All rights reserved.

2006 Cisco Systems, Inc. All rights reserved.

2006 Cisco Systems, Inc. All rights reserved.

3.1.4 Characteristics of a Secure VPNs

Authentication: Authentication ensures that a message comes from an

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

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

protecting the message contents from being intercepted by unauthenticated

2006 Cisco Systems, Inc. All rights reserved.

3.1.5 VPN Security: Encapsulation

2006 Cisco Systems, Inc. All rights reserved.

The three different protocols that tunneling uses are:

2006 Cisco Systems, Inc. All rights reserved.

2006 Cisco Systems, Inc. All rights reserved.

3.1.6 VPN Security: IPsec and GRE

2006 Cisco Systems, Inc. All rights reserved.

2006 Cisco Systems, Inc. All rights reserved.

3.1.7 VPN Security: Symmetric and Asymmetric

2006 Cisco Systems, Inc. All rights reserved.

2006 Cisco Systems, Inc. All rights reserved.

2006 Cisco Systems, Inc. All rights reserved.

3.1.8 Symmetric Encryption Algorithms

2006 Cisco Systems, Inc. All rights reserved.

Symmetric Encryption: DES

2006 Cisco Systems, Inc. All rights reserved.

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

2006 Cisco Systems, Inc. All rights reserved.

Symmetric Encryption: 3DES

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

2006 Cisco Systems, Inc. All rights reserved.

Symmetric Encryption: AES

2006 Cisco Systems, Inc. All rights reserved.

2006 Cisco Systems, Inc. All rights reserved.

3.1.9 Asymetric Encryption

RSA authenticates the remote device while Diffie-Hellman exchanges keys

2006 Cisco Systems, Inc. All rights reserved.

The security of the RSA cryptosystem is based on

2006 Cisco Systems, Inc. All rights reserved.

The question is, how do the encrypting and decrypting devices

2006 Cisco Systems, Inc. All rights reserved.

3.1.10 Diffie-Hellman Key Exchange

2006 Cisco Systems, Inc. All rights reserved.

Classic DH ExampleAlice and Bob

2006 Cisco Systems, Inc. All rights reserved.

2006 Cisco Systems, Inc. All rights reserved.

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

2006 Cisco Systems, Inc. All rights reserved.

2006 Cisco Systems, Inc. All rights reserved.

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