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.