Полезная информация

cc/td/doc/product/software/ios120/12cgcr/secur_c
hometocprevnextglossaryfeedbacksearchhelp
PDF

Table of Contents

Configuring IPSec Network Security

Configuring IPSec Network Security

This chapter describes how to configure IPSec, which is a framework of open standards developed by the Internet Engineering Task Force (IETF). IPSec provides security for transmission of sensitive information over unprotected networks such as the Internet. IPSec acts at the network layer, protecting and authenticating IP packets between participating IPSec devices ("peers"), such as Cisco routers.

IPSec provides the following network security services. These services are optional. In general, local security policy will dictate the use of one or more of these services:


Note The term data authentication is generally used to mean data integrity and data origin authentication. Within this chapter it also includes anti-replay services, unless otherwise specified.

With IPSec, data can be transmitted across a public network without fear of observation, modification, or spoofing. This enables applications such as virtual private networks (VPNs), including intranets, extranets, and remote user access.

For a complete description of the IPSec Network Security commands used in this chapter, refer to the "IPSec Network Security Commands" chapter in the Security Command Reference. To locate documentation of other commands that appear in this chapter, use the command reference master index or search online.

IPSec Overview

IPSec services are similar to those provided by Cisco Encryption Technology (CET), a proprietary security solution introduced in Cisco IOS Software Release 11.2. (The IPSec standard was not yet available at Release 11.2.) However, IPSec provides a more robust security solution and is standards-based. IPSec also provides data authentication and anti-replay services in addition to data confidentiality services, while CET provides only data confidentiality services.

For information comparing IPSec and CET, refer to the chapter "IP Security and Encryption Overview."

Supported Standards

Cisco implements the following standards with this feature:

IPSec is documented in a series of Internet Drafts, all available at http://www.ietf.org/html.charters/ipsec-charter.html (as of the first publication of this document). The overall IPSec implementation is per the latest version of the "Security Architecture for the Internet Protocol" Internet Draft (draft-ietf-arch-sec-xx.txt). An earlier version of IPSec is described in RFCs 1825 through 1829. While Internet Drafts supersede these RFCs, Cisco IOS IPSec implements RFC 1828 (IP Authentication using Keyed MD5) and RFC 1829 (ESP DES-CBC Transform) for backwards compatibility.
For more information on IKE, see the "Configuring Internet Key Exchange Security Protocol" chapter.

The component technologies implemented for IPSec include:

IPSec as implemented in Cisco IOS software supports the following additional standards:

Both the older RFC 1828 AH and the updated AH protocol are implemented. The updated AH protocol is per the latest version of the "IP Authentication Header" Internet Draft (draft-ietf-ipsec-auth-header-xx.txt).
RFC 1828 specifies the Keyed MD5 authentication algorithm; it does not provide anti-replay services. The updated AH protocol allows for the use of various authentication algorithms; Cisco  IOS has implemented the mandatory MD5 and SHA (HMAC variants) authentication algorithms. The updated AH protocol provides anti-replay services.
Both the older RFC 1829 ESP and the updated ESP protocol are implemented. The updated ESP protocol is per the latest version of the "IP Encapsulating Security Payload" Internet Draft (draft-ietf-ipsec-esp-v2-xx.txt).
RFC 1829 specifies DES-CBC as the encryption algorithm; it does not provide data authentication or anti-replay services. The updated ESP protocol allows for the use of various cipher algorithms and (optionally) various authentication algorithms. Cisco IOS implements the mandatory 56-bit DES-CBC with Explicit IV as the encryption algorithm, and MD5 or SHA (HMAC variants) as the authentication algorithms. The updated ESP protocol provides anti-replay services.

List of Terms

anti-replay---A security service where the receiver can reject old or duplicate packets in order to protect itself against replay attacks. IPSec provides this optional service by use of a sequence number combined with the use of data authentication. Cisco IOS IPSec provides this service whenever it provides the data authentication service, except in the following cases:

data authentication---Includes two concepts:

Data authentication can refer either to integrity alone or to both of these concepts (although data origin authentication is dependent upon data integrity).

data confidentiality---A security service where the protected data cannot be observed.

data flow---A grouping of traffic, identified by a combination of source address/mask, destination address/mask, IP next protocol field, and source and destination ports, where the protocol and port fields can have the values of any. In effect, all traffic matching a specific combination of these values is logically grouped together into a data flow. A data flow can represent a single TCP connection between two hosts, or it can represent all of the traffic between two subnets. IPSec protection is applied to data flows.

peer---In the context of this chapter, a peer refers to a router or other device that participates in IPSec.

perfect forward secrecy (PFS)---A cryptographic characteristic associated with a derived shared secret value. With PFS, if one key is compromised, previous and subsequent keys are not compromised, because subsequent keys are not derived from previous keys.

security association---An IPSec security association (SA) is a description of how two or more entities will use security services in the context of a particular security protocol (AH or ESP) to communicate securely on behalf of a particular data flow. It includes such things as the transform and the shared secret keys to be used for protecting the traffic.

The IPSec security association is established either by IKE or by manual user configuration. Security associations are unidirectional and are unique per security protocol. So when security associations are established for IPSec, the security associations (for each protocol) for both directions are established at the same time.

When using IKE to establish the security associations for the data flow, the security associations are established when needed and expire after a period of time (or volume of traffic). If the security associations are manually established, they are established as soon as the necessary configuration is completed and do not expire.

Security parameter index (SPI)---This is a number which, together with a destination IP address and security protocol, uniquely identifies a particular security association. When using IKE to establish the security associations, the SPI for each security association is a pseudo-randomly derived number. Without IKE, the SPI is manually specified for each security association.

transform---A transform lists a security protocol (AH or ESP) with its corresponding algorithms. For example, one transform is the AH protocol with the HMAC-MD5 authentication algorithm; another transform is the ESP protocol with the 56-bit DES encryption algorithm and the HMAC-SHA authentication algorithm.

tunnel---In the context of this chapter, a secure communication path between two peers, such as two routers. It does not refer to using IPSec in tunnel mode.

IPSec Interoperability with Other Cisco IOS Software Features

You can use Cisco Encryption Technology and IPSec together; the two encryption technologies can coexist in your network. Each router may support concurrent encryption links using either IPSec or Cisco Encryption Technology. A single interface can even support the use of IPSec or CET for protecting different data flows.

Supported Hardware, Switching Paths, and Encapsulation

IPSec has certain restrictions for hardware, switching paths, and encapsulation methods as follows.

Supported Hardware

IPSec is not supported on VIP2 interfaces (VIP2-40 or above) or the Encryption Service Adapter (ESA) card. There is currently no hardware accelerator for IPSec.

Supported Switching Paths

IPSec works with both process switching and fast switching. IPSec does not work with optimum or flow switching.

Supported Encapsulation

IPSec works with the following serial encapsulations: High-Level Data-Links Control (HDLC), Point-to-Point Protocol (PPP), and Frame Relay.

IPSec also works with the GRE and IPinIP Layer 3, L2F, and L2TP tunneling protocols; however, multipoint tunnels are not supported. Other Layer 3 tunneling protocols (DLSw, SRB, etc.) are currently not supported for use with IPSec.

Since the IPSec Working Group has not yet addressed the issue of group key distribution, IPSec currently cannot be used to protect group traffic (such as broadcast or multicast traffic).

Restrictions

At this time, IPSec can be applied to unicast IP datagrams only. Because the IPSec Working Group has not yet addressed the issue of group key distribution, IPSec does not currently work with multicasts or broadcast IP datagrams.

If you use Network Address Translation (NAT), you should configure static NAT translations so that IPSec will work properly. In general, NAT translation should occur before the router performs IPSec encapsulation; in other words, IPSec should be working with global addresses.

Overview of How IPSec Works

In simple terms, IPSec provides secure tunnels between two peers, such as two routers. You define which packets are considered sensitive and should be sent through these secure tunnels, and you define the parameters which should be used to protect these sensitive packets, by specifying characteristics of these tunnels. Then, when the IPSec peer sees such a sensitive packet, it sets up the appropriate secure tunnel and sends the packet through the tunnel to the remote peer.


Note The use of the term tunnel in this chapter does not refer to using IPSec in tunnel mode.

More accurately, these tunnels are sets of security associations that are established between two IPSec peers. The security associations define which protocols and algorithms should be applied to sensitive packets, and also specify the keying material to be used by the two peers. Security associations are unidirectional and are established per security protocol (AH or ESP).

With IPSec you define what traffic should be protected between two IPSec peers by configuring access lists and applying these access lists to interfaces by way of crypto map sets. Therefore, traffic may be selected based on source and destination address, and optionally Layer 4 protocol, and port. (Similar to CET, the access lists used for IPSec are used only to determine which traffic should be protected by IPSec, not which traffic should be blocked or permitted through the interface. Separate access lists define blocking and permitting at the interface.

A crypto map set can contain multiple entries, each with a different access list. The crypto map entries are searched in order---the router attempts to match the packet to the access list specified in that entry.

When a packet matches a permit entry in a particular access list, and the corresponding crypto map entry is tagged as cisco, then CET is triggered, and connections are established if necessary. If the crypto map entry is tagged as ipsec-isakmp, IPSec is triggered. If no security association exists that IPSec can use to protect this traffic to the peer, IPSec uses IKE to negotiate with the remote peer to set up the necessary IPSec security associations on behalf of the data flow. The negotiation uses information specified in the crypto map entry as well as the data flow information from the specific access list entry. (The behavior is different for dynamic crypto map entries. Refer to the section "Creating Dynamic Crypto Maps.")

If the crypto map entry is tagged as ipsec-manual, IPSec is triggered. If no security association exists that IPSec can use to protect this traffic to the peer, the traffic is dropped. In this case, the security associations are installed via the configuration, without the intervention of IKE. If the security associations did not exist, IPSec did not have all of the necessary pieces configured.

Once established, the set of security associations (outbound, to the peer) is then applied to the triggering packet as well as to subsequent applicable packets as those packets exit the router. "Applicable" packets are packets that match the same access list criteria that the original packet matched. For example, all applicable packets could be encrypted before being forwarded to the remote peer. The corresponding inbound security associations are used when processing the incoming traffic from that peer.

If IKE is used to establish the security associations, the security associations will have lifetimes so that they will periodically expire and require renegotiation. (This provides an additional level of security.)

Multiple IPSec tunnels can exist between two peers to secure different data streams, with each tunnel using a separate set of security associations. For example, some data streams might be just authenticated while other data streams must both be encrypted and authenticated.

Access lists associated with IPSec crypto map entries also represent which traffic the router requires to be protected by IPSec. Inbound traffic is processed against the crypto map entries---if an unprotected packet matches a permit entry in a particular access list associated with an IPSec crypto map entry, that packet is dropped because it was not sent as an IPSec-protected packet.

Crypto map entries also include transform sets. A transform set is an acceptable combination of security protocols, algorithms and other settings to apply to IPSec protected traffic. During the IPSec security association negotiation, the peers agree to use a particular transform set when protecting a particular data flow.

Nesting of IPSec Traffic to Multiple Peers

You can nest IPSec traffic to a series of IPSec peers. For example, in order for traffic to traverse multiple firewalls (and these firewalls have a policy of not letting through traffic that they themselves have not authenticated), the router needs to establish IPSec tunnels with each firewall in turn. The "nearest" firewall becomes the "outermost" IPSec peer.

In the example shown in Figure 21, Router  A encapsulates the traffic destined for Router  C in IPSec (Router  C is the IPSec peer). However, before Router  A can send this traffic, it must first reencapsulate this traffic in IPSec in order to send it to Router  B (Router  B is the "outermost" IPSec peer).


Figure 21: Nesting Example of IPSec Peers

It is possible for the traffic between the "outer" peers to have one kind of protection (such as data authentication) and for traffic between the "inner" peers to have different protection (such as both data authentication and encryption).

Prerequisites

You need to configure IKE as described in the "Configuring Internet Key Exchange Security Protocol" chapter.

Even if you decide to not use IKE, you still need to disable it as described in the "Configuring Internet Key Exchange Security Protocol" chapter.

IPSec Configuration Task List

After you have completed IKE configuration, configure IPSec. To configure IPSec, complete the tasks in the following sections at each participating IPSec peer.

For IPSec configuration examples, refer to the "IPSec Configuration Example" section located at the end of this chapter.

Ensure Access Lists Are Compatible with IPSec

IKE uses UDP port 500. The IPSec ESP and AH protocols use protocol numbers 50 and 51. Ensure that your access lists are configured so that protocol 50, 51, and UDP port 500 traffic is not blocked at interfaces used by IPSec. In some cases you might need to add a statement to your access lists to explicitly permit this traffic.

Set Global Lifetimes for IPSec Security Associations

You can change the global lifetime values which are used when negotiating new IPSec security associations. (These global lifetime values can be overridden for a particular crypto map entry).

These lifetimes only apply to security associations established via IKE. Manually established security associations do not expire.

There are two lifetimes: a "timed" lifetime and a "traffic-volume" lifetime. A security association expires after the first of these lifetimes is reached. The default lifetimes are 3600 seconds (one hour) and 4,608,000 kilobytes (10 megabytes per second for one hour).

If you change a global lifetime, the new lifetime value will not be applied to currently existing security associations, but will be used in the negotiation of subsequently established security associations. If you wish to use the new values immediately, you can clear all or part of the security association database. Refer to the clear crypto sa command for more details.

IPSec security associations use one or more shared secret keys. These keys and their security associations time out together.

To change a global lifetime for IPSec security associations, use one or more of the following commands in global configuration mode:
Command Purpose

crypto ipsec security-association lifetime seconds seconds

Change the global "timed" lifetime for IPSec SAs.

This command causes the security association to time out after the specified number of seconds have passed.

crypto ipsec security-association lifetime kilobytes kilobytes

Change the global "traffic-volume" lifetime for IPSec SAs.

This command causes the security association to time out after the specified amount of traffic (in kilobytes) have passed through the IPSec "tunnel" using the security association.

clear crypto sa

or

clear crypto sa peer {ip-address | peer-name}

or

clear crypto sa map map-name

or

clear crypto sa entry destination-address protocol spi

(Optional) Clear existing security associations. This causes any existing security associations to expire immediately; future security associations will use the new lifetimes. Otherwise, any existing security associations will expire according to the previously configured lifetimes.

Note Using the clear crypto sa command without parameters will clear out the full SA database, which will clear out active security sessions. You may also specify the peer, map, or entry keywords to clear out only a subset of the SA database. For more information, see the clear crypto sa command.

How These Lifetimes Work

Assuming that the particular crypto map entry does not have lifetime values configured, when the router requests new security associations it will specify its global lifetime values in the request to the peer; it will use this value as the lifetime of the new security associations. When the router receives a negotiation request from the peer, it will use the smaller of either the lifetime value proposed by the peer or the locally configured lifetime value as the lifetime of the new security associations.

The security association (and corresponding keys) will expire according to whichever comes sooner, either after the number of seconds has passed (specified by the seconds keyword) or after the amount of traffic in kilobytes is passed (specified by the kilobytes keyword). Security associations that are established manually (via a crypto map entry marked as ipsec-manual) have an infinite lifetime.

A new security association is negotiated before the lifetime threshold of the existing security association is reached, to ensure that a new security association is ready for use when the old one expires. The new security association is negotiated either 30 seconds before the seconds lifetime expires or when the volume of traffic through the tunnel reaches 256 kilobytes less than the kilobytes lifetime (whichever comes first).

If no traffic has passed through the tunnel during the entire life of the security association, a new security association is not negotiated when the lifetime expires. Instead, a new security association will be negotiated only when IPSec sees another packet that should be protected.

Create Crypto Access Lists

Crypto access lists are used to define which IP traffic will be protected by crypto and which traffic will not be protected by crypto. (These access lists are not the same as regular access lists, which determine what traffic to forward or block at an interface.) For example, access lists can be created to protect all IP traffic between Subnet  A and Subnet  Y or Telnet traffic between Host  A and Host  B.

The access lists themselves are not specific to IPSec---they are no different from what is used for CET. It is the crypto map entry referencing the specific access list that defines whether IPSec or CET processing is applied to the traffic matching a permit in the access list.

Crypto access lists associated with IPSec crypto map entries have four primary functions:

If you want certain traffic to receive one combination of IPSec protection (for example, authentication only) and other traffic to receive a different combination of IPSec protection (for example, both authentication and encryption), you need to create two different crypto access lists to define the two different types of traffic. These different access lists are then used in different crypto map entries which specify different IPSec policies.

Later, you will associate the crypto access lists to particular interfaces when you configure and apply crypto map sets to the interfaces (following instructions in the sections "Create Crypto Map Entries" and "Apply Crypto Map Sets to Interfaces").

To create crypto access lists, use the following command in global configuration mode:
Command Purpose

access-list access-list-number {deny | permit} protocol source source-wildcard destination destination-wildcard [precedence precedence] [tos tos] [log]

or

ip access-list extended name

Follow with permit and deny statements as appropriate.

Specify conditions to determine which IP packets will be protected.1 (Enable or disable crypto for traffic that matches these conditions.)

Cisco recommends that you configure "mirror image" crypto access lists for use by IPSec and that you avoid using the any keyword, as described in the sections "Defining Mirror Image Crypto Access Lists at each IPSec Peer" and "Using the any Keyword in Crypto Access Lists" (following).

Also see the "Crypto Access List Tips" section.

1You specify conditions using an IP access list designated by either a number or a name. The access-list command designates a numbered extended access list; the ip access-list extended command designates a named access list.

Crypto Access List Tips

Using the permit keyword causes all IP traffic that matches the specified conditions to be protected by crypto, using the policy described by the corresponding crypto map entry. Using the deny keyword prevents traffic from being protected by crypto in the context of that particular crypto map entry. (In other words, it does not allow the policy as specified in this crypto map entry to be applied to this traffic.) If this traffic is denied in all of the crypto map entries for that interface, then the traffic is not protected by crypto (either CET or IPSec).

The crypto access list you define will be applied to an interface after you define the corresponding crypto map entry and apply the crypto map set to the interface. Different access lists must be used in different entries of the same crypto map set. (These two tasks are described in following sections.) However, both inbound and outbound traffic will be evaluated against the same "outbound" IPSec access list. Therefore, the access list's criteria is applied in the forward direction to traffic exiting your router, and the reverse direction to traffic entering your router. In Figure 22, IPSec protection is applied to traffic between Host 10.0.0.1 and Host 20.0.0.2 as the data exits Router  A's S0 interface enroute to Host 20.0.0.2. For traffic from Host 10.0.0.1 to Host 20.0.0.2, the access list entry on Router A is evaluated as follows:

source = host 10.0.0.1
dest = host 20.0.0.2

For traffic from Host 20.0.0.2 to Host 10.0.0.1, that same access list entry on Router A is evaluated as follows:

source = host 20.0.0.2
dest = host 10.0.0.1


Figure 22: How Crypto Access Lists Are Applied for Processing IPSec

If you configure multiple statements for a given crypto access list which is used for IPSec, in general the first permit statement that is matched will be the statement used to determine the scope of the IPSec security association. That is, the IPSec security association will be set up to protect traffic that meets the criteria of the matched statement only. Later, if traffic matches a different permit statement of the crypto access list, a new, separate IPSec security association will be negotiated to protect traffic matching the newly matched access list statement.


Note Access
lists for crypto map entries tagged as ipsec-manual are restricted to a single permit entry and subsequent entries are ignored. In other words, the security associations established by that particular crypto map entry are only for a single data flow. To be able to support multiple manually established security associations for different kinds of traffic, define multiple crypto access lists, and then apply each one to a separate ipsec-manual crypto map entry. Each access list should include one permit statement defining what traffic to protect.

Any unprotected inbound traffic that matches a permit entry in the crypto access list for a crypto map entry flagged as IPSec will be dropped, since this traffic was expected to be protected by IPSec.


Note If you view your router's access lists by using a command such as show ip access-lists, all extended IP access lists will be shown in the command output. This includes extended IP access lists that are used for traffic filtering purposes as well as those that are used for crypto. The show command output does not differentiate between the different uses of the extended access lists.

See the Security Command Reference for complete details about the extended IP access list commands used to create IPSec access lists.

Defining Mirror Image Crypto Access Lists at each IPSec Peer

Cisco recommends that for every crypto access list specified for a static crypto map entry that you define at the local peer, you define a "mirror  image" crypto access list at the remote peer. This ensures that traffic that has IPSec protection applied locally can be processed correctly at the remote peer. (The crypto map entries themselves must also support common transforms and must refer to the other system as a peer.)

Figure 23 shows some sample scenarios when you have mirror image access lists and when you do not have mirror image access lists.


Figure 23: Mirror Image vs. Non-Mirror Image Crypto Access Lists (for IPSec)

As Figure 23 indicates, IPSec Security Associations (SAs) can be established as expected whenever the two peers' crypto access lists are mirror images of each other. However, an IPSec SA can be established only some of the time when the access lists are not mirror images of each other. This can happen in the case where an entry in one peer's access list is a subset of an entry in the other peer's access list, such as shown in Cases 3 and 4 of Figure 23. IPSec SA establishment is critical to IPSec---without SAs, IPSec does not work, causing any packets matching the crypto access list criteria to be silently dropped instead of being forwarded with IPSec security.

In Figure 23, an SA cannot be established in Case 4. This is because SAs are always requested according to the crypto access lists at the initiating packet's end. In Case 4, Router  B requests that all traffic between Subnet  X and Subnet  Y be protected, but this is a superset of the specific flows permitted by the crypto access list at Router  A so the request is therefore not permitted. Case 3 works because Router  A's request is a subset of the specific flows permitted by the crypto access list at Router  B.

Because of the complexities introduced when crypto access lists are not configured as mirror images at peer IPSec devices, Cisco strongly encourages you to use mirror image crypto access lists.

Using the any Keyword in Crypto Access Lists

When you create crypto access lists, using the any keyword could cause problems. Cisco discourages the use of the any keyword to specify source or destination addresses.

The any keyword in a permit statement is discouraged when you have multicast traffic flowing through the IPSec interface; the any keyword can cause multicast traffic to fail. (This is true for both CET and IPSEC.)

The permit any any statement is strongly discouraged, as this will cause all outbound traffic to be protected (and all protected traffic sent to the peer specified in the corresponding crypto map entry) and will require protection for all inbound traffic. Then, all inbound packets that lack IPSec protection will be silently dropped, including packets for routing protocols, NTP, echo, echo response, etc. The difference here between CET and IPSec is that CET would attempt to decrypt and then forward the (now garbage) data, while IPSec would simply drop any packets that did not have IPSec protection.

You need to be sure you define which packets to protect. If you must use the any keyword in a permit statement, you must preface that statement with a series of deny statements to filter out any traffic (that would otherwise fall within that permit statement) that you do not want to be protected.

Define Transform Sets

A transform set represents a certain combination of security protocols and algorithms. During the IPSec security association negotiation, the peers agree to use a particular transform set for protecting a particular data flow.

You can specify multiple transform sets, and then specify one or more of these transform sets in a crypto map entry. The transform set defined in the crypto map entry will be used in the IPSec security association negotiation to protect the data flows specified by that crypto map entry's access list.

During IPSec security association negotiations with IKE, the peers search for a transform set that is the same at both peers. When such a transform set is found, it is selected and will be applied to the protected traffic as part of both peers' IPSec security associations.

With manually established security associations, there is no negotiation with the peer, so both sides must specify the same transform set.

If you change a transform set definition, the change is only applied to crypto map entries that reference the transform set. The change will not be applied to existing security associations, but will be used in subsequent negotiations to establish new security associations. If you want the new settings to take effect sooner, you can clear all or part of the security association database by using the clear crypto sa command.

To define a transform set, use the following commands starting in global configuration mode:
Step Command Purpose

1 . 

crypto ipsec transform-set transform-set-name transform1 [transform2 [transform3]]

Define a transform set.

There are complex rules defining which entries you can use for the transform arguments. These rules are explained in the command description for the crypto ipsec transform-set command, and Table 22 provides a list of allowed transform combinations.

This command puts you into the crypto  transform  configuration mode.

2 . 

initialization-vector size [4 | 8]

(Optional) If you specified the esp-rfc1829 transform in the transform set, you can change the initialization vector size to be used with the esp-rfc1829 transform.

3 . 

mode [tunnel | transport]

(Optional) Change the mode associated with the transform set. The mode setting is only applicable to traffic whose source and destination addresses are the IPSec peer addresses; it is ignored for all other traffic. (All other traffic is in tunnel mode only.)

4 . 

exit

Exit the crypto  transform  configuration mode.

5 . 

clear crypto sa

or

clear crypto sa peer {ip-address | peer-name}

or

clear crypto sa map map-name

or

clear crypto sa entry destination-address protocol spi

This step clears existing IPSec security associations so that any changes to a transform set will take effect on subsequently established security associations. (Manually established SAs are reestablished immediately.)

Note Using the clear crypto sa command without parameters will clear out the full SA database, which will clear out active security sessions. You may also specify the peer, map, or entry keywords to clear out only a subset of the SA database. For more information, see the clear crypto sa command.

Table 22 shows allowed transform combinations.


Table 22: Allowed Transform Combinations
AH Transform
pick up to one
ESP Encryption Transform
pick up to one
ESP Authentication Transform
Pick up to one, only if you also selected the esp-des transform (not esp-rfc1829)
Transform Description Transform Description Transform Description

ah-md5-hmac

AH with the MD5 (HMAC  variant) authentication algorithm

esp-des

ESP with the 56-bit DES encryption algorithm

esp-md5-hmac

ESP with the MD5 (HMAC  variant) authentication algorithm

ah-sha-hmac

AH with the SHA (HMAC  variant) authentication algorithm

esp-rfc1829

older version of the ESP protocol (per RFC  1829); does not allow an accompanying ESP authentication transform

esp-sha-hmac

ESP with the SHA (HMAC  variant) authentication algorithm

ah-rfc1828

older version of the AH protocol (per  RFC  1828)

Create Crypto Map Entries

To create crypto map entries, follow the guidelines and tasks described in these sections:

About Crypto Maps

Crypto maps, used with Cisco Encryption Technology (CET) are now expanded to also specify IPSec policy.

Crypto map entries created for IPSec pull together the various parts used to set up IPSec security associations, including:

Crypto map entries with the same crypto map name (but different map sequence numbers) are grouped into a crypto map set. Later, you will apply these crypto map sets to interfaces; then, all IP traffic passing through the interface is evaluated against the applied crypto map set. If a crypto map entry sees outbound IP traffic that should be protected and the crypto map specifies the use of IKE, a security association is negotiated with the remote peer according to the parameters included in the crypto map entry; otherwise, if the crypto map entry specifies the use of manual security associations, a security association should have already been established via configuration. (If a dynamic crypto map entry sees outbound traffic that should be protected and no security association exists, the packet is dropped.)

The policy described in the crypto map entries is used during the negotiation of security associations. If the local router initiates the negotiation, it will use the policy specified in the static crypto map entries to create the offer to be sent to the specified IPSec peer. If the IPSec peer initiates the negotiation, the local router will check the policy from the static crypto map entries, as well as any referenced dynamic crypto map entries to decide whether to accept or reject the peer's request (offer).

For IPSec to succeed between two IPSec peers, both peers' crypto map entries must contain compatible configuration statements.

When two peers try to establish a security association, they must each have at least one crypto map entry that is compatible with one of the other peer's crypto map entries. For two crypto map entries to be compatible, they must at least meet the following criteria:

Load Sharing

You can define multiple remote peers using crypto maps to allow for load sharing. If one peer fails, there will still be a protected path. The peer that packets are actually sent to is determined by the last peer that the router heard from (received either traffic or a negotiation request from) for a given data flow. If the attempt fails with the first peer, IKE tries the next peer on the crypto map list.

If you are not sure how to configure each crypto map parameter to guarantee compatibility with other peers, you might consider configuring dynamic crypto maps as described in the section "Creating Dynamic Crypto Maps." Dynamic crypto maps are useful when the establishment of the IPSec tunnels is initiated by the remote peer (such as in the case of an IPSec router fronting a server). They are not useful if the establishment of the IPSec tunnels is locally initiated, because the dynamic crypto maps are policy templates, not complete statements of policy. (Although the access lists in any referenced dynamic crypto map entry are used for crypto packet filtering.)

How Many Crypto Maps Should You Create?

You can apply only one crypto map set to a single interface. The crypto map set can include a combination of CET, IPSec/IKE, and IPSec/manual entries. Multiple interfaces can share the same crypto map set if you want to apply the same policy to multiple interfaces.

If you create more than one crypto map entry for a given interface, use the seq-num of each map entry to rank the map entries: the lower the seq-num, the higher the priority. At the interface that has the crypto map set, traffic is evaluated against higher priority map entries first.

You must create multiple crypto map entries for a given interface if any of the following conditions exist:

Creating Crypto Map Entries for Establishing Manual Security Associations

The use of manual security associations is a result of a prior arrangement between the users of the local router and the IPSec peer. The two parties may wish to begin with manual security associations, and then move to using security associations established via IKE, or the remote party's system may not support IKE. If IKE is not used for establishing the security associations, there is no negotiation of security associations, so the configuration information in both systems must be the same in order for traffic to be processed successfully by IPSec.

The local router can simultaneously support manual and IKE-established security associations, even within a single crypto map set. There is very little reason to disable IKE on the local router (unless the router only supports manual security associations, which is unlikely).

To create crypto map entries to establish manual security associations (SAs) (that is, when IKE is not used to establish the SAs), use the following commands starting in global configuration mode:
Step Command Purpose

1 . 

crypto map map-name seq-num ipsec-manual

Specify the crypto map entry to create (or modify).

This command puts you into the crypto map configuration mode.

2 . 

match address access-list-id

Name an IPSec access list. This access list determines which traffic should be protected by IPSec and which traffic should not be protected by IPSec security in the context of this crypto map entry. (The access list can specify only one permit entry when IKE is not used.)

3 . 

set peer {hostname | ip-address}

Specify the remote IPSec peer. This is the peer to which IPSec protected traffic should be forwarded.

(Only one peer can be specified when IKE is not used.)

4 . 

set transform-set transform-set-name

Specify which transform set should be used.

This must be the same transform set that is specified in the remote peer's corresponding crypto map entry.

(Only one transform set can be specified when IKE is not used.)

5 . 

set session-key inbound ah spi hex-key-data

and

set session-key outbound ah spi hex-key-data

If the specified transform set includes the AH protocol, set the AH Security Parameter Indexes (SPIs) and keys to apply to inbound and outbound protected traffic.

(This manually specifies the AH security association to be used with protected traffic.)

6 . 

set session-key inbound esp spi cipher hex-key-data [authenticator hex-key-data]

and

set session-key outbound esp spi cipher hex-key-data [authenticator hex-key-data]

If the specified transform set includes the ESP protocol, set the ESP Security Parameter Indexes (SPIs) and keys to apply to inbound and outbound protected traffic. If the transform set includes an ESP cipher algorithm, specify the cipher keys. If the transform set includes an ESP authenticator algorithm, specify the authenticator keys.

(This manually specifies the ESP security association to be used with protected traffic.)

7 . 

exit

Exit crypto-map configuration mode and return to global configuration mode.

Repeat these steps to create additional crypto map entries as required.

Creating Crypto Map Entries that Use IKE to Establish Security Associations

When IKE is used to establish security associations, the IPSec peers can negotiate the settings they will use for the new security associations. This means that you can specify lists (such as lists of acceptable transforms) within the crypto map entry.

To create crypto map entries that will use IKE to establish the security associations, use the following commands starting in global configuration mode:
Step Command Purpose

1 . 

crypto map map-name seq-num ipsec-isakmp

Name the crypto map entry to create (or modify).

This command puts you into the crypto map configuration mode.

2 . 

match address access-list-id

Name an extended access list. This access list determines which traffic should be protected by IPSec and which traffic should not be protected by IPSec security in the context of this crypto map entry.

3 . 

set peer {hostname | ip-address}

Specify a remote IPSec peer. This is the peer to which IPSec protected traffic can be forwarded.

Repeat for multiple remote peers.

4 . 

set transform-set transform-set-name1 [transform-set-name2...transform-set-name6]

Specify which transform sets are allowed for this crypto map entry. List multiple transform sets in order of priority (highest priority first).

5 . 

set security-association lifetime seconds seconds

and/or

set security-association lifetime kilobytes kilobytes

(Optional) If you want the security associations for this crypto map entry to be negotiated using different IPSec security association lifetimes than the global lifetimes, specify a security association lifetime for the crypto map entry.

6 . 

set security-association level per-host

(Optional) Specify that separate security associations should be established for each source/destination host pair.

Without this command, a single IPSec "tunnel" could carry traffic for multiple source hosts and multiple destination hosts.

With this command, when the router requests new security associations it will establish one set for traffic between Host  A and Host  B, and a separate set for traffic between Host  A and Host  C.

Use this command with care, as multiple streams between given subnets can rapidly consume resources.

7 . 

set pfs [group1 | group2]

(Optional) Specify that IPSec should ask for perfect forward secrecy when requesting new security associations for this crypto map entry, or should demand PFS in requests received from the IPSec peer.

8 . 

exit

Exit crypto-map configuration mode and return to global configuration mode.

Repeat these steps to create additional crypto map entries as required.

Creating Dynamic Crypto Maps

Dynamic crypto maps (this requires IKE) can ease IPSec configuration and are recommended for use with networks where the peers are not always predetermined. An example of this is mobile users, who obtain dynamically-assigned IP addresses. First, the mobile clients need to authenticate themselves to the local router's IKE by something other than an IP address, such as a fully qualified domain name. Once authenticated, the security association request can be processed against a dynamic crypto map which is set up to accept requests (matching the specified local policy) from previously unknown peers.

To configure dynamic crypto maps, follow these instructions:

Understand Dynamic Crypto Maps

Dynamic crypto maps are only available for use by IKE.

A dynamic crypto map entry is essentially a crypto map entry without all the parameters configured. It acts as a policy template where the missing parameters are later dynamically configured (as the result of an IPSec negotiation) to match a remote peer's requirements. This allows remote peers to exchange IPSec traffic with the router even if the router does not have a crypto map entry specifically configured to meet all of the remote peer's requirements.

Dynamic crypto maps are not used by the router to initiate new IPSec security associations with remote peers. Dynamic crypto maps are used when a remote peer tries to initiate an IPSec security association with the router. Dynamic crypto maps are also used in evaluating traffic.

A dynamic crypto map set is included by reference as part of a crypto map set. Any crypto map entries that reference dynamic crypto map sets should be the lowest priority crypto map entries in the crypto map set (that is, have the highest sequence numbers) so that the other crypto map entries are evaluated first; that way, the dynamic crypto map set is examined only when the other (static) map entries are not successfully matched.

If the router accepts the peer's request, at the point that it installs the new IPSec security associations it also installs a temporary crypto map entry. This entry is filled in with the results of the negotiation. At this point, the router performs normal processing, using this temporary crypto map entry as a normal entry, even requesting new security associations if the current ones are expiring (based upon the policy specified in the temporary crypto map entry). Once the flow expires (that is, all of the corresponding security associations expire), the temporary crypto map entry is then removed.

For both static and dynamic crypto maps, if unprotected inbound traffic matches a permit statement in an access list, and the corresponding crypto map entry is tagged as "IPSec," then the traffic is dropped because it is not IPSec-protected. (This is because the security policy as specified by the crypto map entry states that this traffic must be IPSec-protected.)

For static crypto map entries, if outbound traffic matches a permit statement in an access list and the corresponding SA is not yet established, the router will initiate new SAs with the remote peer. In the case of dynamic crypto map entries, if no SA existed, the traffic would simply be dropped (since dynamic crypto maps are not used for initiating new SAs).


Note Use care when using the any keyword in permit entries in dynamic crypto maps. If it is possible for the traffic covered by such a permit entry to include multicast or broadcast traffic, the access list should include deny entries for the appropriate address range. Access lists should also include deny entries for network and subnet broadcast traffic, and for any other traffic that should not be IPSec protected.
Create a Dynamic Crypto Map Set

Dynamic crypto map entries, like regular static crypto map entries, are grouped into sets. A set is a group of dynamic crypto map entries all with the same dynamic-map-name but each with a different dynamic-seq-num.

To create a dynamic crypto map entry, use the following commands starting in global configuration mode:
Step Command Purpose

1 . 

crypto dynamic-map dynamic-map-name dynamic-seq-num

Create a dynamic crypto map entry.

2 . 

set transform-set transform-set-name1 [transform-set-name2...transform-set-name6]

Specify which transform sets are allowed for the crypto map entry. List multiple transform sets in order of priority (highest priority first).

This is the only configuration statement required in dynamic crypto map entries.

3 . 

match address access-list-id

(Optional) Name an extended access list. This access list determines which traffic should be protected by IPSec and which traffic should not be protected by IPSec.

If this is configured, the data flow identity proposed by the IPSec peer must fall within a permit statement for this crypto access list.

If this is not configured, the router will accept any data flow identity proposed by the IPSec peer. However, if this is configured but the specified access list does not exist or is empty, the router will drop all packets. This is similar to static crypto maps because they also require that an access list be specified.

Care must be taken if the any keyword is used in the access list, since the access list is used for packet filtering as well as for negotiation.

4 . 

set peer {hostname | ip-address}

(Optional) Specify a remote IPSec peer. Repeat for multiple remote peers.

This is rarely configured in dynamic crypto map entries. Dynamic crypto map entries are often used for unknown remote peers.

5 . 

set security-association lifetime seconds seconds

and/or

set security-association lifetime kilobytes kilobytes

(Optional) If you want the security associations for this crypto map to be negotiated using shorter IPSec security association lifetimes than the globally specified lifetimes, specify a key lifetime for the crypto map entry.

6 . 

set pfs [group1 | group2]

(Optional) Specify that IPSec should ask for perfect forward secrecy when requesting new security associations for this crypto map entry or should demand perfect forward secrecy in requests received from the IPSec peer.

7 . 

exit

Exit crypto-map configuration mode and return to global configuration mode.

Dynamic crypto map entries specify crypto access lists that limit traffic for which IPSec security associations can be established. A dynamic crypto map entry that does not specify an access list will be ignored during traffic filtering. A dynamic crypto map entry with an empty access list causes traffic to be dropped. If there is only one dynamic crypto map entry in the crypto map set, it must specify acceptable transform sets.

Add the Dynamic Crypto Map Set into a Regular (Static) Crypto Map Set

You can add one or more dynamic crypto map sets into a crypto map set, via crypto map entries that reference the dynamic crypto map sets. You should set the crypto map entries referencing dynamic maps to be the lowest priority entries in a crypto map set (that is, have the highest sequence numbers).

To add a dynamic crypto map set into a crypto map set, use the following command in global configuration mode:
Command Purpose

crypto map map-name seq-num ipsec-isakmp dynamic dynamic-map-name

Add a dynamic crypto map set to a static crypto map set.

Apply Crypto Map Sets to Interfaces

You need to apply a crypto map set to each interface through which IPSec or CET traffic will flow. Applying the crypto map set to an interface instructs the router to evaluate all the interface's traffic against the crypto map set and to use the specified policy during connection or security association negotiation on behalf of traffic to be protected by crypto (either CET or IPSec).

To apply a crypto map set to an interface, use the following command in interface configuration mode:
Command Purpose

crypto map map-name

Apply a crypto map set to an interface.

For redundancy, you could apply the same crypto map set to more than one interface. The default behavior is as follows:

If you apply the same crypto map set to multiple interfaces for redundancy purposes, you need to specify an identifying interface. This has the following effects:

One suggestion is to use a loopback interface as the identifying interface.

To specify redundant interfaces and name an identifying interface, use the following command in global configuration mode:
Command Purpose

crypto map map-name local-address interface-id

Permit redundant interfaces to share the same crypto map, using the same local identity.

Monitor and Maintain IPSec

Certain configuration changes will only take effect when negotiating subsequent security associations. If you want the new settings to take immediate effect, you must clear the existing security associations so that they will be re-established with the changed configuration. For manually established security associations, you must clear and reinitialize the security associations or the changes will never take effect. If the router is actively processing IPSec traffic, it is desirable to clear only the portion of the security association database that would be affected by the configuration changes (that is, clear only the security associations established by a given crypto map set). Clearing the full security association database should be reserved for large-scale changes, or when the router is processing very little other IPSec traffic.

To clear (and reinitialize) IPSec security associations, use one of the following commands in global configuration mode:
Command Purpose

clear crypto sa

or

clear crypto sa peer {ip-address | peer-name}

or

clear crypto sa map map-name

or

clear crypto sa entry destination-address protocol spi

Clear IPSec security associations.

Note Using the clear crypto sa command without parameters will clear out the full SA database, which will clear out active security sessions. You may also specify the peer, map, or entry keywords to clear out only a subset of the SA database. For more information, see the clear crypto sa command.

To view information about your IPSec configuration, use one or more of the following commands in EXEC mode:
Command Purpose

show crypto ipsec transform-set

View your transform set configuration.

show crypto map [interface interface | tag map-name]

View your crypto map configuration.

show crypto ipsec sa [map map-name | address | identity] [detail]

View information about IPSec security associations.

show crypto dynamic-map [tag map-name]

View information about dynamic crypto maps.

show crypto ipsec security-association lifetime

View global security association lifetime values.

IPSec Configuration Example

The following is an example of a minimal IPSec configuration where the security associations will be established via IKE. For more information about IKE, see the chapter "Configuring Internet Key Exchange Security Protocol."

An IPSec access list defines which traffic to protect:

access-list 101 permit ip 10.0.0.0 0.0.0.255 10.2.2.0 0.0.0.255

A transform set defines how the traffic will be protected:

crypto ipsec transform-set myset esp-des esp-sha

A crypto map joins together the IPSec access list and transform set and specifies where the protected traffic is sent (the remote IPSec peer):

crypto map toRemoteSite 10 ipsec-isakmp
  match address 101
  set transform-set myset
  set peer 10.2.2.5

The crypto map is applied to an interface:

interface Serial0
  ip address 10.0.0.2
  crypto map toRemoteSite

Note In this example, IKE must be enabled.


hometocprevnextglossaryfeedbacksearchhelp
Copyright 1989-1998 © Cisco Systems Inc.