the best damn cisco internetworking book period phần 8 ppt

Cisco Network Security • Chapter 7 775
RSA
RSA shares many similarities with the DH algorithm in that RSA is also based on multiplying
and factoring large integers. However, RSA is significantly faster than DH, leading to a split in
the asymmetric cryptography field that refers to DH and similar algorithms as Public Key
Distribution Systems (PKDS) and RSA and similar algorithms as PKE. PKDS systems are used as
session-key exchange mechanisms, while PKE systems are generally considered fast enough to
encrypt reasonably small messages. However, PKE systems like RSA are not considered fast
enough to encrypt large amounts of data such as entire file systems or high-speed communica-
tions lines.
RSA, DH, and other asymmetric algorithms use much larger keys than their symmetric
counterparts. Common key sizes include 1024 bits and 2048 bits; the keys need to be this large
because factoring, while still a difficult operation, is much easier to perform than the exhaustive
key search approach used with symmetric algorithms.
The RSA algorithm has been in the public domain since RSA Security placed it there two
weeks before the patent expired in September 2000. It is now freely available for use by anyone,
for any purpose. It commonly used in applications such as PGP and SSH. In fact, you can down-
load a freeware version of PGP from www.pgpi.org/products/pgp/versions/freeware if you want
to experiment and learn more about PKE.
Skeme and Oakley Protocols
The Oakley protocol describes a series of key exchanges, called modes, and details the services
provided by each (for example, perfect forward secrecy for keys, identity protection, and authenti-
cation).The Skeme protocol describes a versatile key exchange technique that provides
anonymity, reputability, and quick key refreshment.Their relationship to Internet Security
Association and Key Management Protocol (ISAKMP) is fairly straightforward: where Oakley
defines modes of exchange, ISAKMP defines phases of when each is applied.
IPsec Concepts
The security architecture for IP (IPsec) is a suite of security services for traffic at the IP layer. It is
an open standard, defined in RFC 2401 and several following RFCs. IPsec was developed by the
IETF as part of IPv6 and can be implemented in IPv4. IPsec is a framework of open standards
that operates at Layer 3 of the OSI model, which means that it can protect communications from

the network layer (IP) and up.
IPsec protocols can supply access control, authentication, data integrity, and confidentiality for
each IP packet between two participating network nodes. IPsec can be used between two hosts
(including clients), a gateway and a host, or two gateways. IPsec establishes a secure tunnel between
endpoints, and provides authentication and encryption services to protect transported data.
IPsec provides two security protocols used for transferring data: Encapsulating Security
Payload (ESP) and Authentication Header (AH). AH provides connectionless integrity, data origin
authentication, and anti-replay service for the IP packet. AH does not encrypt the data, but any
modification of the data would be detected. ESP provides confidentiality through the encryption
www.syngress.com
253_BDCisco_07.qxd 10/15/03 11:37 AM Page 775
776 Chapter 7 • Cisco Network Security
of the payload. Access control is provided through the use and management of keys to control
participation in traffic flows.
The only required encryption algorithm in an IPsec implementation is DES, which is defined
in RFC 1829. DES is considered inadequate protection and is being phased out in favor of
stronger encryption such as 3DES, AES, and Blowfish.To provide authentication features, IPsec
uses the two algorithms HMAC-SHA-1 and HMAC-MD5.
A security association (SA) is the agreement between two systems participating in an IPsec
connection. A SA represents a simplex connection to provide a security service using a selected
policy and keys, between two nodes. A Security Parameter Index (SPI), an IP destination address,
and a protocol identifier are used to identify a particular SA.
The SPI is an arbitrary, 32-bit value selected by the destination system that uniquely identifies
a particular SA among several associations that may exist on a specific node.The protocol identi-
fier can indicate either AH or ESP, but not both. Separate SAs are created for each protocol, and
for each direction between systems. If two systems were using AH and ESP in both directions,
then they would form four SAs.
VPN Terminology
The follow technologies and mechanisms are integral to IPsec operations.
■

Transform-Set Defines IPsec protocols to use for authentication and/or encryption.
■
Crypto Map Binds transform set, the peer, and the data to be encrypted.
■
Dynamic Crypto Map A crypto map before information is provided by the peer.
■
ISAKMP The framework for policy negotiations and key management.
■
Internet Key Exchange (IKE) Authenticates IPsec peers negotiates IKE and IPsec
SAs. Also, it establishes keys for encryption algorithms used by IPsec.
■
MD5 The algorithm used to hash keys and pass the hash instead of passing the key or
password. Hash algorithm used to authenticate packet data.
■
SHA-1 The algorithm used to hash keys and pass the hash instead of passing the key or
password.The hash algorithm used to authenticate packet data.
■
AH Data authentication and integrity for IP packets passed between two different sys-
tems, but not data confidentiality. Applies a keyed one-way hash function to the packet
to create a message digest.
■
ESP Data confidentiality, data origin authentication, integrity, and optional anti-replay.
Encrypts the packet payload and/or authentication packets.
■
DES Employs a 56-bit key to encrypt and decrypt packet data.
■
3DES A variant of the 56-bit DES. Data is broken into 64-bit blocks and processed
three times with three unique 56-bit keys.
■
DH Public key cryptography protocol that allows two parties to establish a shared

secret key used by encryption algorithms over some type of insecure channel.
www.syngress.com
253_BDCisco_07.qxd 10/15/03 11:37 AM Page 776
Cisco Network Security • Chapter 7 777
■
RSA Signatures Public key cryptographic system used for authentication.
■
Certificate Authorities (CA) Digital identification card to each querying device.
IPsec
IPsec’s main design goals are to provide the follow functionality:
■
Data Confidentiality Encrypt packets before transmitting them across a network so
only the communicating peers can read it.
■
Data Integrity Authenticate packets sent by the IPsec sender to ensure the data has
not been altered during transmission. Each peer can determine if a received packet was
changed during transit.
■
Data Origin Authentication Authenticate the source of the IPsec packets sent.The
receiver can check the identity of a packet’s sender.
■
Antireplay The receiver can detect and reject replayed packets, protecting it from
spoofing and MITM attacks.
IPsec Core Layer 3 Protocols: ESP and AH
ESP and AH are the main IPsec protocols used to protect data. Applying AH or ESP to an IP
packet modifies its contents to varying degrees, from the header to the payload. An extra header
is inserted between the IP header and the packet contents. See Figures 7.31 and 7.32 for illustra-
tions of how these transformations are performed.AH provides no confidentiality because no
encryption is used.
N

OTE
AH is always broken by NAT.
www.syngress.com
Figure 7.31 AH Encapsulation
Before Applying IPSec
After Applying AH
Authenticated
Original IP
Header
TCP
Header
Data
AH
Original IP
Header
Data
TCP
Header
253_BDCisco_07.qxd 10/15/03 11:37 AM Page 777
778 Chapter 7 • Cisco Network Security
AH
The AH (RFC2402) provides packet authentication and anti-replay services. AH can be deployed
in either transport or tunnel mode. In transport mode, the AH is inserted after the IP header
and before an upper-layer protocol (such as TCP, UDP, and ICMP), or before any other previ-
ously inserted IPsec headers.
The AH (IP protocol 51) ensures:
■
Data Integrity Calculates a hash of the entire IP packet, including the original IP
header (not including variable fields such as the TTL), the data part of the packet, and
the AH (excluding the field that will contain the calculated hash value) [either Message

Authentication Code (MAC) or a digital signature]. MD5 or SHA-1 uses an extra value
to calculate the hash (known only to the participating parties).The receiver performs
calculations and compares to the sender’s results: if they match, the packet is declared
authentic.
■
Data Origin Authentication The AH provides source IP authentication. Since the
source IP is included in the data, its integrity is guaranteed.
■
Replay Protection The AH uses an IPsec sequence number to protect against replay
attacks.
In order to use Network Address Translation (NAT), you need to configure static NAT trans-
lations.This is due to AH being incompatible with NAT because NAT changes the source IP
address.This, in turn, will break the AH header and cause the packets to be rejected by the IPsec
peer or peers.
ESP
ESP (RFC2406) provides data encryption, data authentication, and optional anti-replay services.
ESP can be used on its own or with AH packet authentication. ESP encapsulates the data and can
be deployed in either transport or tunnel mode. In transport mode, ESP is placed after the IP
www.syngress.com
Figure 7.32 ESP Encapsulation
Before Applying IPSec
After Applying ESP (transport mode)
Original IP
Header
TCP
Header
Data
ESP
Header
Original IP

Header
Data
TCP
Header
ESP
Trailer
ESP
Auth
Encrypted
Authenticated
253_BDCisco_07.qxd 10/15/03 11:37 AM Page 778
Cisco Network Security • Chapter 7 779
header (and any options that it contains), and before the upper layer protocol.This makes ESP
and AH compatible with non-IPsec-compliant routers.
Tunnel mode ESP may be employed in either hosts or security gateways. In tunnel mode,
ESP protects the entire inner IP packet, including the entire inner IP header.The position of ESP
in tunnel mode relative to the outer IP header is the same as for ESP in transport mode.
ESP (IP protocol 50) features:
■
Pads a packet to prevent traffic analysis, and encrypts the result with ciphers such as
DES, 3DES, AES, or Blowfish.
■
Optional authentication using the same algorithms as the AH protocol. Header informa-
tion is not included in the authenticated data, which allows ESP-protected packets to
pass through NAT. Authentication data is calculated after encryption.
■
Optional antireplay features.
ESP can perform most of AH’s functions. ESP works on encapsulation principles: all data is
encrypted and then placed between a header and a trailer.This differentiates it from AH, where
only a header is created.

IPsec Communication Modes:Tunnel and Transport
IPsec has a transport mode and a tunnel mode.Transport mode only affects the data payload and
does not modify the original IP header. In transport mode, the AH or ESP header is inserted
after the IP header, but before any upper-layer protocol headers.
Tunnel mode encapsulates the entire original packet as the data portion of a new packet with
its own IP header. (AH and/or ESP headers are created in both modes.) Transport mode is used
when both the receiver and the sender are endpoints of the communication (for example, two hosts
communicating directly to each other).Tunnel mode is more convenient for site-to site VPNs
because it allows tunneling of traffic through the channel established between two gateways.
Transport Mode
Transport will place an AH or ESP header right after the original IP header and before upper-
layer data (TCP header and application data). If ESP is applied to the packet, only this upper-
layer data is encrypted. If optional ESP authentication is used, only upper-layer data, not the IP
header, is authenticated. If AH is applied to the packet, both the original IP header and the
upper-layer data are authenticated. Figure 7.33 shows what happens to the packet when IPsec is
applied in transport mode.
www.syngress.com
253_BDCisco_07.qxd 10/15/03 11:37 AM Page 779
780 Chapter 7 • Cisco Network Security
AH authenticates the original IP header, but does not protect the fields that are modified in
the course of routing IP packets. ESP only protects what comes after the ESP header. If the secu-
rity policy between two nodes requires a combination of security services, the AH header appears
first after the IP header, followed by the ESP header.This combination of SAs is called an SA
bundle.
Tunnel Mode
Tunnel mode, the most common mode of operation, allows the establishment of an encrypted
and authenticated IP tunnel between two sites.The original packet is encrypted and/or authenti-
cated and encapsulated as the data payload of a new IP packet.The new IP header is added to it
with the destination address of the receiving gateway.The ESP and/or AH header is inserted
between this new header and the data portion.The receiving gateway performs decryption and

authentication of the packet, extracts the original IP packet (including the original source/desti-
nation IPs), and forwards it to the destination network. Figure 7.34 demonstrates the encapsula-
tion performed in tunnel mode.
www.syngress.com
Figure 7.33 Packet Structure in Transport Mode
Before Applying IPSec
After Applying AH
Authenticated (except
for mutable fields
After Applying ESP
Original IP
Header
TCP
Header
Data
AH
Original IP
Header
Data
TCP
Header
ESP
Header
Original IP
Header
Data
TCP
Header
ESP
Trailer

ESP
Auth
Encrypted
Authenticated
253_BDCisco_07.qxd 10/15/03 11:37 AM Page 780
Cisco Network Security • Chapter 7 781
If the AH is used, both the original IP header and the new IP header are protected (authenti-
cated), but if ESP is used, even with the authentication option, only the original IP address, not
the sending gateway’s IP address, is protected.This behavior makes it difficult to spoof an IPsec
packet without knowing many technical parameters.The exclusion of the new IP header from
authenticated data also allows tunnels to pass through devices that perform NAT. When the new
header is created, most of the options from the original IP header are mapped onto the new
one—for example, the ToS field.
In tunnel mode, the original IP header and payload are encapsulated by the IPsec protocols. A
new IP header that specifies the IPsec tunnel destination is prepended to the packet.The original
IP header and its payload are protected by the AH or ESP headers. In Figure 7.34, you can see
that, as in transport mode, AH offers some protection for the entire packet, but does not protect
the fields that are modified in the course of routing IP packets between the IPsec tunnel end-
points. It does, however, completely protect the original IP header.
IPsec Architecture
In simplified terms, IPsec provides three main functions:
■
Authentication only, provided through the AH protocol
■
Authentication and confidentiality (encryption), provided through the ESP protocol
■
Key exchange, provided either manually or through the IKE protocol
www.syngress.com
Figure 7.34 Packet Structure in Tunnel Mode
Before Applying IPsec

AH Tunnel mode
Authenticated
ESP Tunnel mode
Original
IP
Header
TCP
Header
Data
AH
Encrypted
Authenticated
New IP
Header
Original
IP
Header
TCP
Header
Data
New IP
Header
Original
IP
Header
TCP
Header
Data
ESP
Trailer

ESP
Auth
ESP
header
253_BDCisco_07.qxd 10/15/03 11:37 AM Page 781
782 Chapter 7 • Cisco Network Security
IPsec provides secure communications between two endpoints (IPsec peers).These communi-
cations are essentially sets of SAs and define which protocols should be applied to sensitive
packets, as well as the keying between the two peers. Multiple IPsec tunnels can exist between
two peers, securing different data streams, with each communication having a separate set of SAs.
IKE
IKE is a key management protocol used in IPsec to create an authenticated, secure communica-
tion channel between two entities and then negotiate the SAs for IPsec. IKE offers several advan-
tages over manually defined keys (manual keying):
■
Eliminates manual configuration of keys
■
Allows you to specify a lifetime for IPsec SA
■
Allows encryption keys to change during IPsec sessions
■
Supports the use of public key-based authentication and CAs
■
Allows dynamic authentication of peers
ISAKMP and IKE
ISAKMP (RFC 2408) describes authenticated key exchange methods.This is a generic protocol
and is not tied to IPsec or any other key-using protocol. It can be implemented directly over IP
or any transport layer protocol. When partially combined with Oakley (RFC 2412) and Secure
Key Exchange Mechanism (SKEME) key exchange protocols, the result is the IKE (RFC 2409).
Although not strictly correct, the terms IKE and ISAKMP are often used interchangeably, even in

Cisco where IKE is configured with the isakmp command.
IKE negotiates in two phases, both of which use UDP port 500.
1. Phase 1 Peers negotiate and set up a secure, authenticated, bi-directional ISAKMP SA
to handle Phase 2 negotiations. One such SA between a pair of peers can handle negoti-
ations for multiple IPsec SAs.The peers agree on the encryption algorithm, hash algo-
rithm, authentication method, and DH group to exchange keys and information.
Peers mutually authenticate, agree on encryption and authentication algorithms to
protect subsequent IKE traffic, exchange keys via DH, and lastly, establish an IKE SA
(SA). IKE SAs are bi-directional; each IKE connection between peers has only one IKE
SA associated with it.
2. Phase 2 Peers negotiate IPsec (ESP and/or AH) as required. IPsec SAs are unidirec-
tional (a different key is used in each direction) and are always negotiated in pairs to
handle two-way traffic.There may be more than one pair defined between two peers.
They agree on the IPsec protocol, hash algorithm, and encryption algorithm. Multiple
SAs will result from Phase 2 negotiations. An SA is created for the inbound and out-
bound of each protocol used.
IKE Phase 2 negotiates one or more IPsec SAs to be used for the IPsec tunnel between these
peers. It uses key material from IKE Phase 1 to derive IPsec keys.The initiating peer identifies
www.syngress.com
253_BDCisco_07.qxd 10/15/03 11:37 AM Page 782
Cisco Network Security • Chapter 7 783
what traffic it wants to protect and what encryption/authentication algorithms it supports.The
receiving peer then agrees on a single protection set for this traffic and establishes keys needed for
this protection set.
NOTE
Do not confuse IPsec SAs with IKE SAs. IKE SAs create the tunnel used by IPsec SAs.
There is only one IKE SA between two devices, but there can be multiple IPsec SAs for
the same IKE SA.
While having different phases adds some overhead in processing, there are advantages to this
approach:

■
Trust between peers is established in IKE Phase 1 and IKE Phase 2.
■
Key material established in the first phase can be used in the second phase.
■
Renegotiations of the first phase can be assisted by the second-phase data.
IKE Phase 1 has two modes: main mode and aggressive mode. Main mode uses three
exchanges between peers; each exchange consists of two messages, a request, and a reply for a
total of six packets exchanged.
■
First Exchange Negotiates the parameters for protection of the IKE connection.
Initiator sends a proposition that includes one encryption algorithm (DES, 3DES, and so
on) and one authentication algorithms (pre-shared secret, RSA PKE with DH exchange
group 1 and 2, or public key RSA signature (certificates).The receiver selects a pair that
it can support; otherwise, no agreement means that the IKE tunnel cannot be estab-
lished.
■
Second Exchange DH key establishment between peers with exchange of nonces
(hashes that only the other peer can interpret) , which confirm the message was sent by
the same host of the previous exchange.
■
Third Exchange Authentication of the peers using the agreed-on methods: public
keys signatures, PKE, or a pre-shared secret. Protected by an encryption method selected
in the first exchange.
At the end of the first phase, each host has an IKE SA, which specifies all parameters for this
IKE tunnel: the authentication method, the encryption and hashing algorithm, the DH group
used, the lifetime for this IKE SA, and the key values.
Aggressive mode exchanges only three packets.The first two packets in this exchange include
almost everything in one message; each host sends a proposed protection set, DH values and
authentication values.The third packet is for confirmation after the IKE SA is already established.

Everything travels on the wire in cleartext and can be eavesdropped on or spoofed, though the
only effective attack is an DOS to one of the peers.
www.syngress.com
253_BDCisco_07.qxd 10/15/03 11:37 AM Page 783
784 Chapter 7 • Cisco Network Security
Phase 2 quick mode is repeated several times using the same IKE SA established in Phase 1.
Each exchange results in the establishment of two IPsec SAs by each peer. One is used for
inbound protection, and the other for outbound protection. During the exchange, peers agree on
the IPsec SA parameters and send each other a new nonce deriving DH keys from the ones
established in Phase 1. When the IPsec SA lifetime expires, a new SA is negotiated in the same
manner. Figure 7.35 summarizes the flow of the IKE protocol. Phase 2 Quick Mode can use
Perfect Forward Secrecy (PFS) that uses encryption keys not derived from previous ones. PFS is
achieved by performing a new DH key establishment in each quick mode.
Another mode in Phase 2 is new group mode, which is not related to the setup of IPsec
parameters and is used to change the parameters of the DH group used in IKE Phase 1.
SAs
IPsec SAs define how two or more IPsec peers will use security protocols (AH or ESP) to com-
municate securely on behalf of a particular flow. SAs contain the shared secret keys used to pro-
tect data in a particular flow, as well as their lifetimes. SAs are unidirectional connections and are
unique per security protocol (AH or ESP).This means that if both AH and ESP services are
required, two or more SAs have to be created. In a two-way communication, each party has at
least two IPsec SAs: the sender and receiver each have one outgoing SA and one incoming SA, as
shown in Figure 7.36.
www.syngress.com
Figure 7.35 IKE Phases and Modes
Main
Mode
Agressive
Mode
Quick

Mode with
PFS
Quick Mode
without PFS
YES
NO
PFS?
Main or
Agressive?
IPsec Tunnel
Established
New IPsec Tunnel
or Key Renewal.
Phase 1
IKE SA Negotiation
Phase 2
IPsec SA Negotiation (2)
253_BDCisco_07.qxd 10/15/03 11:37 AM Page 784
Cisco Network Security • Chapter 7 785
SAs can be created manually or with IKE. If created manually, the SAs are established as soon
as they are created and do not expire. With IKE, SAs are established when needed and expire
after a certain amount of time, or after a certain volume of traffic.The default lifetimes are 3600
seconds (one hour) and 4,608,000 kilobytes, and are periodically renegotiated.
Each SA can be uniquely identified by three parameters:
■
SPI Pseudo-arbitrary 32-bit value assigned to a SA at creation. Both AH and ESP
always contain a reference to an SPI. When SAs are manually created (IKE is not used),
the SPI has to be manually specified for each SA.
■
IP Destination Address The destination endpoint of the SA (host or network

device).
■
Security Protocol Identifier AH or ESP. SAs specify whether IPsec is used in trans-
port or tunnel mode.
■
Transport Mode SA: Between two hosts.
■
Tunnel Mode SA: Between two gateways or between a gateway and a host.
Use the show crypto IPsec security-association-lifetime syntax to view the lifetimes of
the SAs.
show crypto ipsec security-association-lifetime
Security association lifetime: 4608000 kilobytes/3600 seconds
Each peer maintains a Security Association Database (SAD) of active SAs for each direction
(inbound and outbound) on each of its interfaces. SAs from these databases decide which encryp-
www.syngress.com
Figure 7.36 IPsec SAs and Their use in Two-way Communication
SA21
SA12
SA23
SA32
PIX1
PIX2
PIX3
IPsec tunnel between PIX1 and
PIX2 is protected by two (2) SAs.
PIX1 t0 PIX2 Traffic - SA12
PIX2 to PIX1 Traffic - SA21
IPsec tunnel between PIX2 and
PIX3 is protected by two (2) SAs.
PIX2 t0 PIX3 Traffic - SA23

PIX3 to PIX2 Traffic - SA32
PIX2 has two IPsec tunnel with its
two peers (PIX1 and PIX3). It
maintains four (4) SAs - two (2) for
the tunnel to PIX1 and two (2) for
the tunnel to PIX3.
253_BDCisco_07.qxd 10/15/03 11:37 AM Page 785
786 Chapter 7 • Cisco Network Security
tion and authentication parameters are applied to packets. SAs may be fixed for the time of traffic
flow (manual IPsec). When a key management protocol is used, they are renegotiated many
times during the connection flow. For each SA, the SAD entry contains the following data:
■
Destination address
■
SPI
■
IPsec transform (protocol and algorithm used—for example,AH, HMAC-MD5)
■
Key used in the algorithm
■
IPsec mode (tunnel or transport)
■
SA lifetime (in kilobytes or in seconds); when this lifetime expires, the SA must be ter-
minated, and a new SA established
■
Anti-replay sequence counters
■
Optional parameters such as Path MTU
The selection of encryption parameters and corresponding SAs is governed by another
database, the Security Policy Database (SPD). An SPD is maintained for each interface and is used

to decide:
■
The selection of outgoing traffic to be protected
■
Checking if incoming traffic was properly protected
■
Τηε SAs to use for protecting this traffic
■
What to do if the SA for this traffic does not exist
SPD specifies what security services are to be applied to IP packets and how, and distin-
guishes between protected and non-protected traffic.The SPD consists of a numbered list of poli-
cies, each associated with one or more selectors (ACLs). A permit statement means that IPsec
should be applied to the matching traffic; a deny statement means that the packet should be for-
warded and IPsec not applied. SPD policies are configured with the crypto map command.The
resulting map and a crypto ACL are applied to the interface, creating an SPD for this interface.
For outgoing traffic, when the IPsec network stack layer receives data to be sent, it consults
the SPD to determine if the traffic has to be protected. If it does, the SPD is used to recover a SA
that corresponds to this traffic. If the SA exists, its characteristics are taken from the SAD and
applied to the packet. If the SA does not exist yet, IKE is called upon to establish a new SA, and
then the packet is protected with characteristics of this SA.
For incoming IPsec traffic, the SPI is recovered from the AH or ESP header, then used to
find a corresponding SA in the SAD. If it does not exist, the packet is dropped. If an SA exists,
the packet is checked/decrypted.The SPD is checked to ensure that this packet was correctly
protected—for example, that it should have been encrypted using 3DES and authenticated with
MD5 and nothing else. Figure 7.37 shows both sequences of events.
www.syngress.com
253_BDCisco_07.qxd 10/15/03 11:37 AM Page 786
Cisco Network Security • Chapter 7 787
VPN Operation
There is often confusion over how IPsec, IKE, and ISAKMP work together to create a VPN.The

flowchart in Figure 7.38 shows how they interoperate.Traffic entering the router is checked against
an ACL associated with the crypto map applied to the ingress interface. A match triggers a check to
determine if there is an IPsec SA with the peer for this traffic. If so, the traffic is encrypted and sent
out the interface. If not, the router will check to see if it has an ISAKMP SA. If so, IKE will nego-
tiate the IPsec keys and SAs necessary to encrypt and forward the traffic. If there is no ISAKMP
SA, IKE will negotiate an IPsec SA, encrypt the data, and forward the traffic.
www.syngress.com
Figure 7.37 Processing of Outbound and Inbound Traffic by IPsec
Outbound
Inbound
PIX1
PIX2
IP
Packet
Protected by
IPsec?
Which policy?
SPD


SAD


IPsec
Packet
To Pix2
Apply IPsec
tranforms.
Insert SPI.
IPsec

Packet
SAD


SPD


IP
Packet
Extract SPI and
find corresponding
SA.
Process packet per
its SA.
Determine SA
and SPI for
packet.
253_BDCisco_07.qxd 10/15/03 11:37 AM Page 787
788 Chapter 7 • Cisco Network Security
Authentication Methods
IPsec peers must negotiate and authenticate each other using a common authentication protocol.
Multiple authentication methods are supported.
■
Preshared Keys The same key is preconfigured on each peer.The peers authenticate
each other by computing and sending a keyed hash of data that includes the preshared
key. If the receiving side can independently re-create the same hash using its preshared
key, it knows that both parties must share the same key.
■
PKE Each party generates a pseudo-random number (nonce) and encrypts it in the
other party’s public key.The parties authenticate each other by computing a keyed hash

www.syngress.com
Figure 7.38 Interaction between IPsec, IKE, and ISAKMP
Traffic matches
list for
encryption?
Is there an IPsec
SA for this
traffic?
Has IKE
negotiated
ISAKMP keys
and SA?
Authenticate
peer and
negotiate
ISAKMP SA.
Traffic is Not
Encrypted.
Send traffic
out interface.
Encrypt and
forward.
Use IKE (inside
ISAKMP) to
negotiate an
IPsec SA.
YES
NO
NO
NO

YES
YES
Traffic
Bad Authentication
Good Authentication and SA
253_BDCisco_07.qxd 10/15/03 11:37 AM Page 788
Cisco Network Security • Chapter 7 789
containing the other peer’s nonce, decrypted with the local private key as well as other
publicly and privately available information.
■
Digital Signatures Each peer digitally signs a set of data and sends it to the other
party.This method is similar to the public key cryptography one, except that it provides
nonrepudiation (the ability for a third party to prove that a communication between the
two parties took place).
Digital Certificates
When using digital certificates, each peer identifies itself by sending its name, its public certificate
issued by a CA, and its RSA signature. A public key certificate contains a copy of the party’s
public key.The receiving party queries the same CA (of course, this CA should be trusted by the
receiving party) to confirm that the certificate really belongs to the sender. If it does, the RSA
signature is verified using the public key from the certificate, and the system’s identity is verified.
This scheme is easily scalable, especially in partial- or full-mesh environments. When a new peer
is added to the IPsec network, the administrator only needs to enroll it with the CA and obtain a
certificate from the CA.
To receive a certificate, a system must establish a trusted channel with the CA, generate a
public/private key pair, and request a certificate.The CA then verifies the system’s credentials
somehow (usually using offline methods) and issues a certificate. A certificate can include the
bearer’s IP address, its name, the serial number of the certificate, the expiry date of the certificate,
and a copy of the bearer’s public key.The standard for the certificate format is X.509, of which
Cisco supports version 3.
Cisco and VeriSign, Inc. co-developed a certificate management protocol called Certificate

Enrollment Protocol (CEP), an early implementation of Certificate Request Syntax (CRS). CEP
specifies how a device communicates with a CA, including how to retrieve the CA’s public key,
how to enroll a device with the CA, and how to retrieve a certificate revocation list (CRL). CEP
uses RSA’s public key cryptography standards (PKCS) 7 and 10 as key technologies.The IETF’s
Public Key Infrastructure (PKI) Working Group is working to standardize a protocol for these
functions.
Figure 7.39 shows an example of multiple routers in a mesh topology where key manage-
ment is not performed via a CA. Every time a new router is added, keys need to be created
between each of the participating IPsec routers.
www.syngress.com
253_BDCisco_07.qxd 10/15/03 11:37 AM Page 789
790 Chapter 7 • Cisco Network Security
As an example, if you wanted to add an additional router to Figure 7.39, four additional two-
part keys would be required to add just a single encryption router.The key’s numbers grow expo-
nentially as you add more routers and the configuration and management of these keys becomes
problematic. A CA offers an ideal solution to such an environment. Figure 7.40 shows a typical
scenario where key management is performed through a CA.
IPsec Limitations
One of the few limitations of IPsec is that it only supports unicast IP datagrams. No support for
multicasts or broadcasts is currently provided. IPsec can have a significant impact on network per-
www.syngress.com
Figure 7.39 Management without Certificate Authority
Figure 7.40 Key Management with CA
Certificate
Authority
253_BDCisco_07.qxd 10/15/03 11:37 AM Page 790
Cisco Network Security • Chapter 7 791
formance. One of the drawbacks of network layer encryption is that it does complicate network
troubleshooting and debugging. IDS sensors cannot analyze IPsec packets and determine if the
packet contains any suspicious information.

Configuring ISAKMP/IKE
Unless you are doing manual IPsec, you should first configure ISAKMP policy to define the
security parameters to be used in IKE negotiation. A peer must match one of the configured
policies to begin negotiating the SA. No match, no SA, and therefore no VPN. Define and
number an ISAKMP policy. Numbering enables you to have multiple policies and multiple peers.
The lowest policy number takes precedence. In our example in Figure 7.41, we only need a
single policy:
Central(config)# crypto isakmp policy 100
Determine the encryption protocol for data confidentiality (here we use DES):
Central(config-isakmp)# encryption des
Define which hash algorithm to use.This could be MD5 or SHA.
Central(config-isakmp)# hash md5
www.syngress.com
Figure 7.41 Corporate to Branch Office VPN
Servers
Branch Network
Sales Workstation
Sales Workstation
Customer Service
Customer Service
Sales
Workgroup
10.2.3.0
Servers
HQ Network
HQ Workstation
HQ Workstation
HQ Workstation
HQ Workstation
Accounting

Engineering
Research
Corp E-mail
10.2.2.0
192.168.5.2
192.168.5.1
Central
Branch
Corporate
Branch
253_BDCisco_07.qxd 10/15/03 11:37 AM Page 791
792 Chapter 7 • Cisco Network Security
Determine how the peers will authenticate each other.This can be done with pre-shared keys
or digital certificates.
Central(config-isakmp)# authentication pre-share
Specify the DH 768-bit group identifier.
Central(config-isakmp)# group 1
Pre-shared keys require the identity of each peer: its hostname or IP address.The default is IP
addresses for peer identity.
Central(config)# crypto isakmp identity address
Specify the pre-shared key and the identity (the IP address) of the encryption peer.The key
will need to be the same on both ends.
Central(config-isakmp)# crypto isakmp key secretkey address 192.168.5.1
Verify the ISAKMP configuration.
Central router# show crypto isakmp policy
The show crypto isakmp policy displays the parameters of ISAKMP.
Protection suite of priority 100
encryption algorithm: DES - Data Encryption Standard (56 bit keys).
hash algorithm: Message Digest 5
Authentication method: Pre-Shared Key

Diffie-Hellman group: #1 (768 bit)
Lifetime: 86400 seconds, no volume limit
Default protection suite
encryption algorithm: DES - Data Encryption Standard (56 bit keys).
hash algorithm: Secure Hash Standard
authentication method: Rivest-Shamir-Adleman Signature
Diffie-Hellman group: #1 (768 bit)
lifetime: 86400 seconds, no volume limit
Next, configure the Branch router.The ISAKMP policy for the Branch router will be similar
to the Central router. After we finish the ISAKMP parameters on both routers, we will move on
to configuring IPsec.
Configuring IPsec
The first step in defining IPsec is to determine what traffic will be encrypted as specified in
ACLs.These ACLs are used to define what traffic is encrypted/decrypted and what traffic is not.
The crypto map references the ACL to IPsec and is applied to the interface.
Configure an ACL to define traffic that needs to be encrypted.You will configure a “mirror”
ACL on the remote peer:
www.syngress.com
253_BDCisco_07.qxd 10/15/03 11:37 AM Page 792
Cisco Network Security • Chapter 7 793
Central(config)# access-list 120 permit ip 10.2.2.0 0.0.0.255 10.2.3.0 0.0.0.255
Define a transform set that defines the authentication and encryption or data confiden-
tiality you will use for IPsec.The first argument (esp-md5-hmac) defines the message hash for
authentication; the second argument (esp-des) defines that the encryption will be 56-bit DES.
Central(config)# crypto ipsec transform-set MYSET esp-md5-hmac esp-des
Build the crypto map, which must contain compatible configurations between peers. Crypto
map configurations are compatible if:
■
Crypto map entries have “mirror” image ACLs, or in the case of a dynamic crypto map,
the local crypto is permitted by the remote dynamic map.

■
Crypto map entries properly identify the peer(s).
■
Crypto map entries have at least one transform set in common between peers.
Name and number crypto maps identify the key negotiation and SA to be performed with
ISAKMP:
Central(config)# crypto map MYMAP 2 ipsec-isakmp
Bind the previously defined ACL with the crypto map.
Central(config-crypto-map)# match address 120
Define the peer that we will be doing IPsec with:
Central(config-crypto-map)# set peer 192.168.5.1
Associate the transform set we want to use with the crypto map:
Central(config-crypto-map)# set transform-set MYSET
Apply it to the interface on the router.
Central(config)# interface serial0/1
Central(config-if)# crypto map MYMAP
Deploy a similar configuration on the Branch router.
To see your crypto map configuration on the Central router, issue the show crypto map
command.
Central# show crypto map
Crypto Map "MYMAP” 2 ipsec-isakmp
Peer = 192.168.5.1
Extended IP access list 120
access-list 120 permit ip 10.2.2.0 0.0.0.255 10.2.3.0 0.0.0.255
Current peer: 192.168.5.1
Security association lifetime: 4608000 kilobytes/3600 seconds
PFS (Y/N): N
Transform sets={ MYSET, }
www.syngress.com
253_BDCisco_07.qxd 10/15/03 11:37 AM Page 793

794 Chapter 7 • Cisco Network Security
View the Branch router crypto map.
Central# show crypto map
Crypto Map "MYMAP" 2 ipsec-isakmp
Peer = 192.168.5.2
Extended IP access list 120
access-list 120 permit ip 10.2.3.0 0.0.0.255 10.2.2.0 0.0.0.255
Current peer: 192.168.5.2
Security association lifetime: 4608000 kilobytes/3600 seconds
PFS (Y/N): N
Transform sets={ MYSET, }
If you make changes to a crypto map, transform set, or any other item relating to your VPN,
it may be necessary to issue the clear crypto sa command.This will clear the existing IPsec SAs
so that renegotiation takes place and the changes are implemented immediately.
RAS VPN
Figure 7.42 shows a NAS providing access to the internal network using a dial-in connection. We
do not want to pass information through the Public Switched Telephone Network (PSTN)
unencrypted.The VPN tunnel will terminate on the asynchronous interface we use to dial in on.
The VPN client is not limited to dial-up. It can be used across any type of network interface
running TCP/IP. Let’s begin our configuration on the NAS router.
www.syngress.com
Figure 7.42 Enterprise Dial-up VPN
Servers
Accounting
Engineering
Research
Corp E-mail
Branch
Central
NAS

172.16.10.11
Dial in User
Firewall
(Internet Traffic)
Internet
253_BDCisco_07.qxd 10/15/03 11:37 AM Page 794
Cisco Network Security • Chapter 7 795
Configuring IPsec on the NAS
Create the IPsec transform set.
RouterNAS(config)# crypto ipsec transform-set vpnclient esp-des esp-shahmac
Create the ISAKMP policy.
RouterNAS(config)# crypto isakmp policy 100
RouterNAS(config-isakmp)# hash md5
RouterNAS(config-isakmp)# authentication pre-share
Configure a shared key and identify the peer.
RouterNAS(config)# crypto isakmp key dialclient address 10.1.1.1
Configure an ACL defining the traffic to be encrypted.This list will specify that any inside
host with a destination of the VPN client (10.1.1.1) will get encrypted.
RouterNAS(config)# access-list 130 permit ip any host 10.1.1.1
Create a crypto map and associate the previous configurations.
RouterNAS(config)# crypto map dialclient 10 ipsec-isakmp
RouterNAS(config-crypto-map)# set peer 10.1.1.1
RouterNAS(config-crypto-map)# set transform-set vpnclient
RouterNAS(config-crypto-map)# match address 130
Apply the crypto map to the interface.
RouterNAS(config-if)# crypto map dialclient
Configure the VPN client as appropriate and establish your VPN to the NAS.
Configuring Cisco IPsec
The following examples show how IPsec can be used to encrypt and protect network traffic
between two networks.

NOTE
When using ACLs or any form of filtering, remember that IKE uses UDP port 500 and
IPsec ESP and AH use protocol numbers 50 and 51. These ports and protocols must not
be blocked.
In very simplified terms IPsec is configured by:
1. Creating a SA (either manually or by using IKE)
2. Defining the SPD (ACLs that specify which traffic is to be secured)
3. Applying these ACLs to an interface by way of crypto map sets
www.syngress.com
253_BDCisco_07.qxd 10/15/03 11:37 AM Page 795
796 Chapter 7 • Cisco Network Security
IPsec Manual Keying Configuration
The following example (Figure 7.43) illustrates the use of IPsec Manual Keying to encrypt
TCP/IP traffic between the 10.1.1.0/24 and 10.1.3.0/24 networks.
If a host on network 10.1.1.x wants to send a packet to a host on network 10.1.3.x, the packet
from host 10.1.1.x is sent in cleartext to the Capetown router.The Capetown router uses the IPsec
tunnel between the Capetown and London router to encrypt the packet and sends it to the
London router that decrypts the packet and sends it to the host on network 10.1.3.x in cleartext.
NOTE
In IOS release 12.0, the crypto map statement set security-association inbound… has
changed to set session-key inbound…
Capetown
no crypto isakmp enable
!
crypto ipsec transform-set encrypt-des esp-des
!
crypto map test 8 ipsec-manual
set peer 10.1.2.2
set security-association inbound esp 1000 cipher ****************
authenticator 01

set security-association outbound esp 1001 cipher ****************
authenticator 01
set transform-set encrypt-des
match address 100
!
interface Serial0/0
ip address 10.1.2.1 255.255.255.0
www.syngress.com
Figure 7.43 Network Diagram for IPsec Manual Keying
Capetown
London
Network
10.1.1.x
Network
10.1.3.x
10.1.1.1
10.1.2.1
10.1.2.2
10.1.3.1
253_BDCisco_07.qxd 10/15/03 11:37 AM Page 796
Cisco Network Security • Chapter 7 797
no ip route-cache
no ip mroute-cache
crypto map test
!
interface Ethernet1/0
ip address 10.1.1.1 255.255.255.0
!
access-list 100 permit ip 10.1.1.0 0.0.0.255 10.1.3.0 0.0.0.255
!

London
!
no crypto isakmp enable
!
crypto ipsec transform-set encrypt-des esp-des
!
crypto map test 8 ipsec-manual
set peer 10.1.2.1
set security-association inbound esp 1001 cipher **************** authenticator 01
set security-association outbound esp 1000 cipher **************** authenticator 01
set transform-set encrypt-des
match address 100
!
interface Ethernet0/0
ip address 10.1.3.1 255.255.255.0
!
interface Serial0/0
ip address 10.1.2.2 255.255.255.0
no ip route-cache
no ip mroute-cache
no fair-queue
crypto map test
!
access-list 100 permit ip 10.1.3.0 0.0.0.255 10.1.1.0 0.0.0.255
To verify and debug the preceding example, use the show crypto engine connections
active and show crypto ipsec sa commands.
capetown# show crypto engine connections active
ID Interface IP-Address State Algorithm Encrypt Decrypt
1 Serial0/0 10.1.2.1 set DES_56_CBC 235 0
2 Serial0/0 10.1.2.1 set DES_56_CBC 0 236

www.syngress.com
253_BDCisco_07.qxd 10/15/03 11:37 AM Page 797
798 Chapter 7 • Cisco Network Security
The show crypto engine connections active command shows active encryption connec-
tions for all crypto engines. Of particular interest are the encrypt counters that show encryption
is working.
capetown# show crypto ipsec sa
interface: Serial0/0
Crypto map tag: test, local addr. 10.1.2.1
local ident (addr/mask/prot/port): (10.1.1.0/255.255.255.0/0/0)
remote ident (addr/mask/prot/port): (10.1.3.0/255.255.255.0/0/0)
current_peer: 10.1.2.2
PERMIT, flags={origin_is_acl,}
#pkts encaps: 235, #pkts encrypt: 235, #pkts digest 0
#pkts decaps: 236, #pkts decrypt: 236, #pkts verify 0
#send errors 0, #recv errors 0
local crypto endpt.: 10.1.2.1, remote crypto endpt.: 10.1.2.2
path mtu 1500, media mtu 1500
current outbound spi: 3E9
inbound esp sas:
spi: 0x3E8(1000)
transform: esp-des ,
in use settings ={Tunnel, }
slot: 0, conn id: 2, crypto map: test
no sa timing
IV size: 8 bytes
replay detection support: N
inbound ah sas:
outbound esp sas:
spi: 0x3E9(1001)

transform: esp-des ,
in use settings ={Tunnel, }
slot: 0, conn id: 1, crypto map: test
no sa timing
IV size: 8 bytes
replay detection support: N
outbound ah sas:
The show crypto ipsec sa command shows the settings used by current SAs. Of particular
interest are local and remote crypto endpoints, the transform set used (encryption algorithm), and
statistics of the packets encrypted and decrypted.
www.syngress.com
253_BDCisco_07.qxd 10/15/03 11:37 AM Page 798
Cisco Network Security • Chapter 7 799
IPsec over GRE Tunnel Configuration
Figure 7.44 illustrates the use of IPsec over a GRE tunnel to encrypt non-IP-based traffic. In this
example, Novell’s Internetwork Packet Exchange (IPX) was used, but the same example holds
true for other non-IP-based protocols such as AppleTalk. Please note that DES is no longer con-
sidered secure and wherever possible, a stronger cipher such as 3DES or AES should be used.
Dubai
crypto isakmp policy 10
authentication pre-share
group 2
lifetime 3600
crypto isakmp key ****** address 10.1.5.1
!
crypto ipsec transform-set tunnelset esp-des esp-md5-hmac
!
crypto map toBoston local-address Loopback0
crypto map toBoston 10 ipsec-isakmp
set peer 10.1.5.1

set transform-set tunnelset
match address 101
!
interface Loopback0
ip address 10.1.4.1 255.255.255.0
!
interface Tunnel0
no ip address
no ip route-cache
no ip mroute-cache
ipx network A3
tunnel source Serial0/0
tunnel destination 10.1.2.2
www.syngress.com
Figure 7.44 Network Diagram for IPsec over a GRE Tunnel
Dubai Boston
Network
10.1.1.x
Network
10.1.3.x
10.1.1.1
10.1.2.1
10.1.2.2
10.1.3.1
GRE Tunnel
IPX A3
IPX A1 IPX A2
253_BDCisco_07.qxd 10/15/03 11:37 AM Page 799