ISAKMP/IKE Phase 1 Policies

ISAKMP IKE Phase 1 Policies

One of the first steps you'll take in setting up IPsecL2L or remote accessis to define your ISAKMP policies for your ISAKMP/IKE Phase 1 management connection. The following subsections will discuss how to create your policies and the following section will define how to configure the device authentication information you've chosen for your Phase 1 policies.

Enabling ISAKMP

If you have a router with the IPsec feature, ISAKMP/IKE is enabled by default. To enable or disable it, use the following command:

Router(config)# [no] crypto isakmp enable

You need to disable ISAKMP/IKE only if the remote peers do not support it, in which case you'll have to configure all parameters and keys for the data connection manually instead of having ISAKMP/IKE negotiate the parameters and create keying material dynamically; however, this is rarely done.

Creating Policies

An ISAKMP/IKE policy defines how the management connection is to be created, authenticated, and protected. You can have more than one policy on your router. You might need to do this if your router has multiple peers and each peer has different abilities or policy configurations. If you own the entire network and all the routers are Cisco routers, typically you would have a single policy that would encompass any management connection to any of your peering Cisco routers.

A single ISAKMP/IKE policy contains the following parameters: prioritization or sequence number, encryption algorithm, hashing function, authentication method, DH key group, and connection lifetime. Here are the commands to create a policy for the management connection:

Router(config)# crypto isakmp policy priority
Router(config-isakmp)# encryption {des | 3des | aes}
Router(config-isakmp)# hash {sha | md5}
Router(config-isakmp)# authentication {rsa-sig | rsa-encr | pre-share}
Router(config-isakmp)# group {1 | 2 | 5}
Router(config-isakmp)# lifetime seconds
Router(config-isakmp)# exit

The crypto isakmp policy command creates a unique ISAKMP/IKE management connection policy on the router, where each policy requires a separate number. Numbers can range between 110,000. Executing this command takes you to a subcommand mode where you enter the configuration for the policy. The encryption command specifies which encryption algorithm to use; the hash command specifies the HMAC function to use; the authentication command specifies the method to use for device authentication (you'll also need to configure the actual authentication information that you have decided to use, discussed in the "ISAKMP/IKE Phase 1 Device Authentication" section later); the group command specifies the DH key group to use; and the lifetime command specifies the lifetime of the management connection. If you don't specify a particular parameter in a policy, it has a default value, as follows:

• Encryption algorithm: DES
• HMAC function: SHA-1
• Authentication method: RSA signatures (certificates)
• DH group: 1
• Lifetime: 86,400 seconds

Likewise, a default, unnumbered ISAKMP/IKE policy exists on the router with the above configured values; so if these are sufficient, you don't need to configure an ISAKMP/IKE policy on your router. However, if you do create a policy, the pre-configured router policy always has the lowest priority. Also, you can use the default command within the ISAKMP policy to set a parameter back to the Cisco default value for the specified policy:

Router(config)# crypto isakmp policy priority
Router(config-isakmp)# default {encryption | hash | authentication |
 group | lifetime}
Router(config-isakmp)# exit

Tip

The lower the policy number, the higher the priority for the ISAKMP policy, affecting which policy will be used between a peer. Therefore, give the most secure policy the lowest number (like 1) and the least secure policy the highest number (like 10000). The next section of this chapter discusses how a policy is chosen between two peers.

To view your ISAKMP policies, use the show crypto isakmp policy command shown in Example 16-1; this example has one configured policy (10) and the default policy.

Example 16-1. The show crypto isakmp policy Command

Router# show crypto isakmp policy
Global IKE policy
Protection suite of priority 10
 encryption algorithm: AES - Advanced Encryption Standard
 (128 bit keys).
 hash algorithm: Message Digest 5
 authentication method: Pre-Shared Key
 Diffie-Hellman group: #2 (1024 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

 

Negotiating Policies with Peers

For two peers to establish an IPsec management connection, at least one configured ISAKMP/IKE policy on each peer must match. The peer that initiates the connection sends its entire list of management connection policies to the remote peer. The remote peer then looks for a match by comparing the sender's highest priority policy (lowest number, in the case of Cisco), against the local policies. These are processed based on the sequence numbers, from the lowest number to the highest. If no match is found, the remote peer compares the sender's second highest priority policy to its local list of policies (from the lowest to the highest), and so on until a match is found. Based on this process, the initiator of the connection has influence over which policy is used. Once a match is found, DH is performed and then the device authentication method that was negotiated. If no match is found, the negotiation fails and the management connection is not built.

Note

For a match to occur between two Phase 1 policies, the encryption algorithm, hashing function, DH group, and authentication method must match; if the lifetimes don't match, the shorter lifetime value between the two peers should be used. However, in real life, I've experienced problems with this process between Cisco and non-Cisco equipment where I also had to match the lifetime values for the policy negotiation to succeed.

Let's look at an example of policies on two devices in Examples 16-2 and 16-3, where I'll assume RouterA initiates the connection to RouterB. RouterA sends its two policies to RouterB. RouterB then compares its highest priority policy (1) to RouterA's 1, which doesn't match. RouterB then compares its policy 2 to RouterA's policy 1. In this instance, all of the values match except the lifetime; therefore, the policy is used with the lesser lifetime (3,600 seconds). Even if RouterB initiated the connection to RouterA, the same outcome would occur.

Example 16-2. Phase 1 Policies on RouterA

RouterA(config)# crypto isakmp policy 1
RouterA(config-isakmp)# authentication pre-share
RouterA(config-isakmp)# encryption 3des
RouterA(config-isakmp)# group 2
RouterA(config-isakmp)# lifetime 3600
RouterA(config-isakmp)# exit
RouterA(config)# crypto isakmp policy 2
RouterA(config-isakmp)# authentication pre-share
RouterA(config-isakmp)# hash md5
RouterA(config-isakmp)# exit

 

Example 16-3. Phase 1 Policies on RouterB

RouterB(config)# crypto isakmp policy 1
RouterB(config-isakmp)# authentication pre-share
RouterB(config-isakmp)# hash md5
RouterB(config-isakmp)# exit
RouterB(config)# crypto isakmp policy 2
RouterB(config-isakmp)# authentication pre-share
RouterB(config-isakmp)# encryption 3des
RouterB(config-isakmp)# group 2
RouterB(config-isakmp)# lifetime 86400
RouterB(config-isakmp)# exit

 

Enabling IKE Dead Peer Detection

Another feature that is commonly used for Cisco IPsec sessions is Dead Peer Detection (DPD). DPD allows Cisco IPsec peers to discover a dead peer using a keepalive mechanism across the management connection. DPD can work in one of two modes:

• periodic the peer always sends periodic keepalives to ensure that the remote peer is still alive.
• on-demand the peer sends a message based on traffic patterns between the peers, where the local peer has a question about the liveliness of the remote peer. This is triggered only when the local peer has no traffic to send and is not receiving traffic from the remote peer; otherwise, a remote peer will be found to be dead upon re-keying for the management or data connections.

Note

Like ISAKMP/IKE Phase 1 policies, the use of DPD, when configured, is negotiated between the two peers; if one peer doesn't support it or has it enabled, then DPD is not used. I highly recommend the use of DPD because it speeds up the process of discovering a dead peer and setting up a tunnel to a backup peer (if this has been configured).

To configure DPD, use the following command:

Router(config)# crypto isakmp keepalive seconds [retries]
 [periodic | on-demand]

The first time value that you enter is the number of seconds between DPD messages. The retries parameter specifies the number of seconds between DPD retries when a response is not received for an initial DPD query. If you don't specify the DPD mode, it defaults to on-demand. The crypto isakmp keepalive command is useful only if you have multiple peers defined for redundancy and the primary peer fails; DPD will be able to detect this and will allow the router to bring up the connection to a backup peer.

Note

There is no show command to see the configuration of DPD (with the exception of show running-config); to see DPD in operation, you have to use the debug crypto isakmp command, which I discuss in Chapter 19, "Troubleshooting Router Connections").

Tip

You can use the debug crypto isakmp command to troubleshoot Phase 1 problems. I'll discuss this command in more depth in Chapter 19.