The good news is only four tasks are required to configure IPSec for preshared keys. The bad news is each task has multiple tasks that can initially seem overwhelming. The four tasks Cisco uses, which you can expect on the exam, are as follows:
Task 1 Prepare for IKE and IPSec
Task 2 Configure IKE
Task 3 Configure IPSec
Task 4 Test and verify IPSec
Don’t make this more complicated than necessary. Task 1 is nothing more than making sure you’ve tested the existing network and gathered the information you need for Tasks 2 and 3. Task 2 is configuring for IKE Phase 1, while Task 3 is configuring for IKE Phase 2. Finally, Task 4 is checking your work.
The following task list shows the four tasks broken down into their individual steps. The steps are numbered to include the task number, as well as to help keep them straight. These steps are repeated in the chapter summary with the key commands listed for each step.
Figure 10-1 shows the networks that provide an example scenario used throughout this chapter. The goal is to create a secure VPN tunnel between Rtr1 at the company main office, and Rtr2 at one of almost 100 branch offices in North America, Europe, and Africa. The assumption is this: the main office has reserved networks 192.168.0.0 through 192.168.127.0 for itself and will use one class C for each branch in the remaining 192.168.128.0 to 192.168.255.0 addresses.
Task 1 Prepare for IKE and IPSec
Step 1-1 Identify IPSec peers
Step 1-2 Determine the IKE (IKE Phase 1) policies
Step 1-3 Determine the IPSec (IKE Phase 2) policies
Step 1-4 Check the current configuration
Step 1-5 Ensure the network works without encryption
Step 1-6 Ensure access control lists are compatible with IPSec
Task 2 Configure IKE
Step 2-1 Enable or disable IKE
Step 2-2 Create IKE policies
Step 2-3 Configure preshared keys
Step 2-4 Verify the IKE configuration
Task 3 Configure IPSec
Step 3-1 Configure transform set suites
Step 3-2 Configure global IPSec security association lifetimes
Step 3-3 Configure crypto ACLs
Step 3-4 Configure crypto maps
Step 3-5 Apply the crypto maps to the interface
Task 4 Test and verify IPSec
Step 4-1 Display the configured IKE policies
Step 4-2 Display the configured transform sets
Step 4-3 Display the current state of the IPSec SAs
Step 4-4 Display the configured crypto maps
Step 4-5 Debug IKE events
Step 4-6 Debug IPSec events
The example uses private addresses to avoid using public addresses that might belong to others and to make it easier for those who choose to try to create the configuration in a test lab.
Successful implementation of an IPSec network requires testing of the existing network and advance planning before any configuration begins. Insufficient testing and planning can lead to troubleshooting problems or configuration errors. Some preparation and planning steps include the following:
Step 1-1 Identify IPSec peers
Step 1-2 Determine the IKE (IKE Phase 1) policies
Step 1-3 Determine the IPSec (IKE Phase 2) policies
Step 1-4 Check the current configuration
Step 1-5 Ensure the network works without encryption
Step 1-6 Ensure Access Control Lists are compatible with IPSec
The actual order of these steps could be varied based on personal preferences and implementation circumstances.
An important part of defining a comprehensive IPSec policy is to identify the IPSec peer pairs that must be configured. In the chapter scenario, expanded in Figure 10-2, each remote site will connect only to the Main Office router and, therefore, requires only simple configuration. The Cisco router at the Main Office must be configured for peer communications with each of the remote sites and telecommuter(s). Each peer must support IPSec. Because many different types of peer devices exist, it’s important to identify all potential peers and determine their VPN capabilities. Possible peer devices could include, but aren’t limited to, the following:
Cisco routers
Cisco Secure PIX Firewalls
Cisco Secure VPN 3000 Concentrators
Cisco Secure VPN 3002 Hardware Client device
Cisco Secure VPN Software Client
Other vendor IPSec products that conform to IPSec standards
CA servers
Figure 10-2: Chapter scenario network showing peer connections
It’s important to recognize that IPSec features supported and default settings can vary between Cisco product families, as well as versions of the operating system (OS) being used. This is most important for the Main Office router in the scenario because it must be able to establish common IKE and IPSec policies with each remote device. This also demonstrates why many companies limit the number of devices supported by defining standards for telecommuters or branch offices.
The result of this analysis might be a table like the following:
Location |
Device |
Version (or OS) |
---|---|---|
Main Office |
Cisco 7100 router |
12.2(8)T with FW and VPN |
Telecommuters (24) |
Cisco 900 Cable/DSL router |
12.2(8)T with FW and VPN supports 3DES |
Mobile users (16) |
Cisco VPN Software Client |
v3.6-3DES |
Branch offices (80) North America |
Cisco 2600/3600 routers |
12.2(8)T with FW and VPN supports 3DES |
Branch offices (20) Europe/Africa |
Cisco 2600/3600 routers |
12.2(8)T with FW and VPN supports DES only |
Manufacturing (1) |
Cisco PIX 525 Firewall |
OS v6.2-3DES |
IKE is a hybrid protocol that implements the Oakley key exchange and the Skeme key exchange inside the Internet Security Association and Key Management Protocol (ISAKMP) framework. (ISAKMP, Oakley, and Skeme are security protocols implemented by IKE.)
The purpose of IKE Phase 1 is to authenticate the peers and negotiate a secure session between those peers. This creates a stable platform for IKE Phase 2 to negotiate the IPSec tunnel. The word “negotiate” makes this sound like a complex process, which might involve contentious arguments late into the night. In reality, at each phase, the session instigator submits one or more security policies, which will then be compared by the destination peer against its preconfigured security policies. If a match is found, a session is then established. If no match is found, the session is terminated. From a practical standpoint, if a VPN session can’t be established between the two peers, then one of the devices must be configured to include a set of policies acceptable to the other.
The objective here is to develop one or more IKE security policies based on the overall company security policy. Each policy will require decisions about five security options: authentication method, encryption algorithm, hashing algorithm, Diffie-Hellman group, and SA lifetime. This can make IKE seem more complicated than it is. To get some perspective, we aren’t configuring a connection to an unknown or an untrusted entity. Instead, we’re connecting a branch of the company to the main office system. Chances are both are governed by the same security policy so, while some choices must be made, the list of possibilities shouldn’t be infinite.
In many cases, the decision could be that 3DES will be the encryption, MD5 will perform hashing functions, preshared keys will be used for authentication, and so forth, and that would be configured on each router. So, why have multiple policies with different option combinations? The answer depends on the router and the number of VPN connections that it needs to support. In our example, if each branch only connects to the main office, then they only need the policy that matches the main office router.
The main office router could need a couple of IKE policy choices because all branch offices might be unable to support the same policy. This might not be a vendor or a product platform issue, but a legal issue. While all the North American branches can be configured with 3DES encryption, export controls could prevent the foreign branches from using anything but DES. So, a second policy needs to be available for those connections.
The following table shows the five security features that must be decided, including the current options, defaults, and which choice provides the greatest security. A good idea is always to confirm these options and defaults as IOS versions change. It only makes sense that the IOS will assimilate new IPSec standards as they’re established.
Parameter |
Choices |
Keyword |
Default |
Strongest |
---|---|---|---|---|
Message encryption algorithm |
DES 3DES |
des 3des |
des |
3des |
Message integrity - hash algorithm |
SHA-1 (HMAC variant) MD5 (HMAC variant) |
sha md5 |
sha |
sha |
Peer authentication method |
RSA signatures RSA encrypted nonces preshared keys |
rsa-sig rsa-encr pre-share |
rsa-sig |
rsa-sig |
Diffie-Hellman group (key exchange)* |
768 bit 1,024 bit |
1 2 |
1 |
2 |
IKE SA lifetime |
60 to 86,400 seconds | ? |
86,400 |
60 |
*Some VPN devices support D-H group 5 (1,568 bit), but it might be a while before IOS devices support this level of key exchange.
To complete the IKE planning process, what would make sense is to create a table of the preferred combination of security features, plus one or more fallback options for those devices or locations that can’t support the preferred package. The resulting table might look like the following:
Parameter |
Preferred (stronger) |
2nd Choice |
3rd Choice |
---|---|---|---|
Encryption algorithm |
3des |
des |
des |
Hash algorithm |
sha |
sha |
md5 |
Authentication method |
preshare |
preshare |
preshare |
DH key exchange group |
2 |
2 |
1 |
IKE SA lifetime |
43,200 |
43,200 |
86,400 |
In comparing the two tables, you should see that RSA-SIG would be a preferred authentication method over preshared keys. This chapter deals with using preshared keys, while Chapter 12 covers Certificate Authority (RSA-SIG). RSA encrypted nonces are addressed in the last section of this chapter.
Note? |
You can’t use SHA together with DES encryption on Cisco’s VPN software client version 3.6. Part of the problem with determining a set of preferences is being aware of the different platform limitations. |
Using our scenario for this chapter, the Preferred column represents our configuration preferences for all North American branches and would be the only options configured. The 2nd Choice column would be for those overseas branches that can support the Preferred configuration, except for the export restriction on triple DES. Assuming they don’t form VPN sessions with anyone else, this would be the only choice configured on those devices. The 3rd Choice column might represent extremely small branches or telecommuters using small personal routers with limited resources and options. This also represents the lowest level of parameter options the main office will accept for a VPN connection. The only device that will have all three choices configured is the main office router.
Because any parameter that isn’t defined will use the existing default value, the actual table could look like the following example. Either table can be used in Task 2 to configure the IKE parameters.
Parameter |
Preferred (stronger) |
2nd Choice |
3rd Choice |
---|---|---|---|
Encryption algorithm |
3des | ? | ? |
Hash algorithm | ? | ? |
md5 |
Authentication method |
preshare |
preshare |
preshare |
DH key exchange group |
2 |
2 | ? |
IKE SA lifetime |
43,200 |
43,200 | ? |
Once the choices are made for IKE Phase 1, it’s time to turn to those parameters required to complete IKE Phase 1. This is where the IPSec tunnel is negotiated and, ultimately, the IPSec SAs established. As in Phase 1, the goal is to define one or more sets of IPSec security parameters defining the IPSec security policy, based on the overall company security policy.
The information gathered is required in Task 3 when IPSec is configured. To facilitate that process, gather the following information into a table similar to the one developed for Phase 1 for each peer for which sessions will be established.
Transforms (or transform sets) |
IPSec transforms or build transform sets, plus the VPN mode to provide the optimal security and performance balance |
Peer address |
Peer IP address for this session |
Peer host name |
What is the peer host name for this session? |
IP address to protect |
Which source hosts are to be protected for this session? |
Traffic to protect |
What applications should be protected for this session? |
SA establishment method |
Will SAs be manually established or established via IKE? |
Most of the choices to be configured, such as peer address and host name, are straight-forward. The transforms or, if necessary, the transform sets, involve determining the security features required, and then striking a balance between security level and performance implications. Chapter 9 introduced Transforms and Task 3, later in this chapter, looks at configuring them.
The following table might represent the IPSec values for the chapter scenario:
Parameter |
Site 1 |
Site 2 |
---|---|---|
Transform (set) |
esp-des, tunnel |
esp-des, tunnel |
Peer host name |
Rtr2 |
Rtr1 |
Peer IP address |
10.0.50.2 |
10.0.1.21 |
Hosts to be encrypted |
192.168.0.0/25 |
192.168.30.0/24 |
Traffic to be encrypted |
TCP |
TCP |
SA establishment |
ipsec-isakmp |
ipsec-isakmp |
It’s important to check the current Cisco router configuration to see if any existing IPSec policies are configured that could be useful for, or interfere with, the new IPSec policies. If appropriate, previously configured IKE and IPSec policies can be used to save configuration time. This section looks at three commands useful in discovering existing IKE and IPSec policies.
The basic show running-config command is always a good starting point. In the following partial output, the lines in boldface are the IKE and IPSec configuration statements.
Rtr2#show run ! hostname Rtr2 ! enable secret 5 $1$ojfF$eAp7xa0hU4E678XaibAQa ! crypto isakmp policy 1 hash md5 authentication pre-share crypto isakmp key test_key1 address 10.0.1.21 ! crypto ipsec transform-set trans1 esp-3des crypto ipsec transform-set trans2 ah-md5-hmac esp-des crypto ipsec transform-set trans3 esp-sha-hmac esp-null ! crypto map test_map1 1 ipsec-isakmp ? set peer 10.0.1.21 set security-association lifetime seconds 43200 set transform-set trans1 trans2 trans3 match address 101 ! interface Ethernet0 ip address 192.168.130.1 255.255.255.0 no mop enabled ! interface Serial0 ip address 10.0.50.2 255.255.255.252 no ip mroute-cache no fair-queue crypto map test_map1 ! ip classless ip route 0.0.0.0 0.0.0.0 10.0.50.1 access-list 101 permit tcp 192.168.130.0 0.0.0.255 192.168.0.0 0.0.127.255 dialer-list 1 protocol ip permit !
The following is an example of the output from the show crypto isakmp policy command, which can be used to view all existing IKE policies. Notice the default parameters are displays at the bottom of the output.
Rtr1#show crypto isakmp policy Protection suite of priority 100 ???????encryption algorithm: ??DES - Data Encryption Standard (56 bit keys). ???????hash algorithm: ????????Secure Hash Standard ???????authentication method: ?Pre-Shared Key ???????Diffie-Hellman group: ??#2 (1024 bit) ???????lifetime: ??????????????43200 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 Rtr1#
The show crypto map command is useful for displaying any previously configured crypto maps. If possible, these can be used to save configuration time, but they can interfere with the new IPSec policy.
Rtr1#show crypto map Crypto Map "testmap" 50 ipsec-isakmp ???????Description: VPN Link to branch office in Tacoma, WA ???????Peer = 10.0.50.2 ???????Extended IP access list 125 ???????????access-list 125 permit tcp 192.168.0.0 0.0.127.255 192.168.130.0 ?0.0.0.255 ???????Current peer: 10.0.50.2 ???????Security association lifetime: 2300000 kilobytes/1800 seconds ???????PFS (Y/N): Y ???????DH group: ?group2 ???????Transform sets={ CPU-HOG, } ???????Interfaces using crypto map testmap: ???????????????????Serial0 Rtr1#
The show crypto ipsec transform-set command can be used to view previously configured transform sets. Whenever possible, these transforms can, and should, be used to save configuration time.
Rtr1# show crypto ipsec transform-set Transform set MD5-DES: { esp-des esp-md5-hmac ?} ??will negotiate = { Tunnel, ?}, Transform set DES-ONLY: { esp-des ?} ??will negotiate = { Tunnel, ?}, Transform set CPU-HOG: { ah-md5-hmac ?} ??will negotiate = { Tunnel, ?}, ??{ esp-des esp-md5-hmac ?} ??will negotiate = { Tunnel, ?}, Transform set AH-ONLY: { ah-sha-hmac ?} ??will negotiate = { Tunnel, ?}, Rtr1#
All peer-to-peer connectivity must be verified before configuring IPSec encryption. Basic troubleshooting techniques become more difficult, if not impossible, once encryption is in place.
While the router ping command can be used to verify basic connectivity between peers, equally important is that all important applications and related data are confirmed to be accessible. This can only be accomplished by testing those applications before beginning IPSec configuration.
Skipping this step can lead to wasted time trying to debug IPSec configuration only to discover eventually that the underlying connectivity was never tested. A simple rule of thumb is this type of mistake is always exposed when it can embarrass you the most.
Make certain any existing access lists on VPN device and perimeter router don’t block IPSec traffic. Perimeter routers frequently implement restrictive security policies using ACLs. These policies often deny all inbound traffic that isn’t responding to a specific outbound request. This restriction often blocks inbound IPSec traffic necessary to establish a VPN session.
Specific permit statements must be added to the inbound ACL to allow IPSec traffic. The following ports and protocol access should be left open:
IKE/ISAKMP UDP port 500/keyword: isakmp
Encapsulating Security Payload (ESP) IP protocol number 50/keyword: esp
Authentication Header (AH) IP protocol number 51/keyword: ahp
The first step is to use the show access-lists command to determine if any ACLs will block IPSec traffic.
Assuming an inbound ACL is causing problems, it must be edited, placing entries at the beginning to permit IPSec traffic. The following shows an example of the lines that should be added to Rtr2’s existing ACL 110.
Rtr2# show running-config ! interface Serial 0 ip address 10.0.50.2 255.255.255.252 ip access-group 110 in ! access-list 110 permit ahp host 10.0.1.21 host 10.0.50.2 access-list 110 permit esp host 10.0.1.21 host 10.0.50.2 access-list 110 permit udp host 10.0.1.21 host 10.0.50.2 eq isakmp ???---balance of ACL statements---
The second major task in configuring the IPSec VPN is to configure the IKE parameters gathered in Task 1, Step 2. Configuring IKE involves the following four steps:
Step 2-1 Enable or disable IKE
Step 2-2 Create IKE policies
Step 2-3 Configure preshared keys
Step 2-4 Verify the IKE configuration
This section looks at these four steps and the associated commands.
The first step in configuring IKE is to make sure IKE is globally enabled. While IKE is enabled globally by default, the crypto isakmp enable command makes sure the feature is on. Use the no form of the command to disable IKE. Because IKE is a global mode command, it needn’t be enabled or disabled for individual interfaces. Some circumstances might warrant using an ACL entry to block ISAKMP access (UDP port 500) on interfaces not being used for IPSec to reduce the chances of a denial of service (DoS) attack. The command syntax and an example follow.
Rtr2(config)# crypto isakmp enable Rtr2(config)# no crypto isakmp enable
Now, it’s time to define a suite of ISAKMP (IKE) policy details gathered during the planning task, Task 1, Step 2 (repeated in the following with defaults in italics). The goal is to create a suite of IKE policies, so you can establish IKE peering between two IPSec endpoints.
Parameter |
Preferred (stronger) |
2nd Choice |
3rd Choice |
---|---|---|---|
Encryption algorithm |
3des |
des |
des |
Hash algorithm |
sha |
sha |
md5 |
Authentication method |
preshare |
preshare |
preshare |
DH key exchange group |
2 |
2 |
1 |
IKE SA lifetime |
43,200 |
43,200 |
86,400 |
Using the scenario example, Rtr2 only needing to connect to Rtr1, might be configured with only the preferred (most secure) set of parameters because that set will also be on Rtr1. On the other hand, Rtr1, needing to peer with various devices both domestically and internationally, might need multiple policies to accommodate the different peers. The trick is to configure the policies, so the preferred policy is evaluated by the peer first, and then the second and third choices. This ensures the agreed policy is always the highest mutually agreeable choice.
Use the global crypto isakmp policy command to define an IKE policy containing a set of parameters used during IKE negotiation. Use the no form of this command to delete an IKE policy. The command syntax and an example follow.
Rtr1(config)#[no] crypto isakmp policy priority
Rtr1(config)#crypto isakmp policy 100 Rtr1(config-isakmp)#
priority |
Unique identifier for the IKE policy used to order, or prioritize, the policies. Acceptable range 1 to 10,000 with 1 being the highest possible priority. |
This command invokes the ISAKMP policy configuration (config-isakmp) mode, which allows the six IKE parameters to be defined. The no form of each parameter removes that setting. Exit is used to end the session and any undefined parameters use the default values. The actual choices ware based on the table made in Task 1, Step 2. The following shows the syntax for each parameter, followed by the entries for the preferred policy.
Rtr1#conf t Rtr1(config)#crypto isakmp policy 100 Rtr1(config-isakmp)#authentication {pre-share | rsa-encr | rsa-sig} Rtr1(config-isakmp)#encryption {des | 3des} ?(depending on feature set) Rtr1(config-isakmp)#hash {md5 | sha} Rtr1(config-isakmp)#group {1 | 2} Rtr1(config-isakmp)#lifetime <60 to 86400 seconds> Rtr1(config)#crypto isakmp policy 100 Rtr1(config-isakmp)#authentication pre-share ? Rtr1(config-isakmp)#encryption 3des Rtr1(config-isakmp)#hash sha Rtr1(config-isakmp)#group 2 Rtr1(config-isakmp)#lifetime 43200 Rtr1(config-isakmp)#exit
Because the preferred policy was assigned 100 as a priority, the second and third choices must be progressively larger to control the order in which they’re offered to a peer. A possible choice might be 200 and 300, respectively, enabling newer policies to be assigned priorities that would allow them to be prioritized according to changes in the company security policy. Using 1, 2, and 3 might initially be easy to understand, but it could force reconfiguring the devices if a new feature like AES encryption is implemented.
The following shows the steps to configure the second and third preference, taking advantage of default values to save configuration:
Rtr1#conf t Rtr1(config)#crypto isakmp policy 200 Rtr1(config-isakmp)#authentication pre-share Rtr1(config-isakmp)#group 2 Rtr1(config-isakmp)#lifetime 43200 Rtr1(config-isakmp)#crypto isakmp policy 300 Rtr1(config-isakmp)#authentication pre-share Rtr1(config-isakmp)#hash md5 Rtr1(config-isakmp)#exit
Assuming the chapter scenario, if each branch will only be connecting VPNs to the main office, configuring only one of the IKE policies for each branch should be necessary. Assuming the domestic branches can all support 3DES, policy 100 would seem appropriate. For any foreign branches that can’t use 3DES because of export restrictions, then policy 200 seems the likely candidate. If any branch initiates a session with the main office, both peers would have the same policy. The same is true for a session initiated by the main office to any branch; even the foreign branches could accept the second policy offered.
This whole discussion is based on using a single IKE policy between peers for any encrypted traffic. If the security policy called for 3DES for only certain types of traffic and DES for others, then configuring a second policy on the remote peers would be necessary.
Use the show crypto isakmp policy command to verify the entries, display the default policy, and confirm that the nonconfigured parameters took on the default values.
Rtr1#show crypto isakmp policy Protection suite of priority 100 ???????encryption algorithm: ??3DES - Triple DES (168 bit keys). ???????hash algorithm: ????????Secure Hash Standard ???????authentication method: ?Pre-Shared Key ???????Diffie-Hellman group: ??#2 (1024 bit) ???????lifetime: ??????????????43200 seconds, no volume limit Protection suite of priority 200 ???????encryption algorithm: ??DES - Data Encryption Standard (56 bit keys). ???????hash algorithm: ????????Secure Hash Standard ???????authentication method: ?Pre-Shared Key ???????Diffie-Hellman group: ??#2 (1024 bit) ???????lifetime: ??????????????43200 seconds, no volume limit Protection suite of priority 300 ???????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 Rtr1#
Note? |
Although the output shows “no volume limit” for the lifetimes, currently it is only possible to configure a time IKE lifetime (such as 86,400 seconds); volume limit lifetimes aren’t used. |
IPSec peers authenticate each other during IKE negotiations using the preshared key and their IKE identity. The IKE identity can either be the device IP address or the host name. The router IOS defaults to the IP address and doesn’t add a line to the configuration, unless the host name option is used.
To use the host name identity method, use the global crypto isakmp identity command. The no form of this command resets the default value (address). The command syntax is as follows:
Rtr1(config)#[no] crypto isakmp identity {address | hostname}
Rtr1(config)#crypto isakmp identity hostname
Using the host name identity method makes the most sense if a DNS server is available on the network to resolve the name. If not, the following example shows using an IP Host command entry on the router to handle the name resolution:
Rtr1(config)#ip host Rtr2.domain.com 10.0.50.2
Use the global crypto isakmp key command to configure a preshared authentication key whenever you specify preshared keys in an ISAKMP policy. Use the no form of the command to delete a preshared authentication key. The command syntax for both the address and the host name option is as follows:
Rtr1(config)#[no] crypto isakmp key keystring address peer-address [mask]
Rtr1(config)#[no] crypto isakmp key keystring hostname peer-hostname
keystring |
The preshared key. Any combination of alphanumeric characters up to 128 bytes. Must be identical on both peers. |
mask |
(Optional) Defines a subnet address for the remote peer. Indicates the remote peer ISAKMP identity will be established using the preshared key only. With the mask, keys are no longer restricted to only two users. Added v12.1(1)T. |
A given preshared key is shared between two peer devices. While it’s possible for Rtr1 in the scenario to use the same key with all remote peers, the more secure approach is to use different keys with each pair of peers.
The next example shows IKE and preshared key (cisco123) for Rtr1 and Rtr2 using the address identity method. The IKE policies are compatible. Because the hash algorithm SHA-1 is the default value, it needn’t be configured.
Rtr1(config)#crypto isakmp key cisco123 address 10.0.50.2 Rtr1(config)#crypto isakmp policy 100 Rtr1(config-isakmp)#authentication pre-share ? Rtr1(config-isakmp)#encryption 3des Rtr1(config-isakmp)#group 2 Rtr1(config-isakmp)#lifetime 43200 Rtr1(config-isakmp)#exit Rtr2(config)#crypto isakmp key cisco123 address 10.0.1.21 Rtr2(config)#crypto isakmp policy 100 Rtr2(config-isakmp)#authentication pre-share ? Rtr2(config-isakmp)#encryption 3des Rtr2(config-isakmp)#group 2 Rtr2(config-isakmp)#lifetime 43200 Rtr2(config-isakmp)#exit
Because both devices are under the administrative policies of a single entity, it makes sense that the policy priority value might be the same on both devices. That isn’t a requirement, though, and it would be unlikely when the two peers are from different organizations. The important thing is the parameters are the same.
Note? |
One exception to matching parameters is the lifetime can be shorter on the destination peer and that value will be used. The shorter of the two lifetimes is always used. A shorter lifetime, in theory, increases the security. |
Use the show crypto isakmp policy command to display configured and default policies. An example of IKE policy for Rtr1 is shown in the Step 2-2 section. The show running-config command can also be useful, but the parameters using default values are omitted for brevity.
The next major task in configuring Cisco IOS IPSec is to configure the IPSec parameters gathered in Task 1, Step 3. The general steps used to configure IPSec encryption on Cisco routers are summarized as follows. This chapter looks at each configuration step in detail.
Step 3-1 Configure transform set suites
Step 3-2 Configure global IPSec security association lifetimes
Step 3-3 Configure crypto ACLs
Step 3-4 Configure crypto maps
Step 3-5 Apply the crypto maps to the interface
In Chapter 9, an IPSec transform was defined as a single IPSec security protocol—AH or ESP—with its associated security algorithms and mode. Technically, a transform is the list of operations done on a dataflow to provide data authentication, data confidentiality, and since IOS v12.2(8) data compression. Some of the supported transform choices are shown in Figure 10-3.
The actual transforms supported might vary by device type. VPN devices could support a slightly different group than the PIX Firewall. The following are transforms supported by the IOS-based devices:
AH Transforms—Pick up to one:
Transform |
Description |
---|---|
ah-md5-hmac |
AH with the MD5 (HMAC variant) authentication algorithm |
ah-sha-hmac |
AH with the SHA-1 (HMAC variant) authentication algorithm |
ESP Encryption Transforms—Pick up to one:
Transform |
Description |
---|---|
esp-des |
ESP with the 56-bit DES encryption algorithm |
esp-3des |
ESP with the 168-bit DES (Triple DES) encryption algorithm |
Esp-null |
ESP without cipher. Can be used with esp-md5-hmac or esp-sha-hmac for ESP authentication without encryption. Shouldn’t be used in a production network because of the lack of security |
ESP Authentication Transform—pick up to one, but only if you also selected the esp-des or esp-3des transform (not esp-rfc1829):
Transform |
Description |
---|---|
esp-md5-hmac |
ESP with the MD5 (HMAC variant) authentication algorithm |
esp-sha-hmac |
ESP with the SHA-1 (HMAC variant) authentication algorithm |
IP Compression Transform—pick up to one:
Transform |
Description |
---|---|
comp-lzs |
IP compression with the LZS algorithm. (IOS v12.2((8)) or later) |
The compression algorithm used in the comp-lzs transform is Lempel-Ziv-Stac (LZS) compression, the most widely accepted lossless compression algorithm at this time. Compression is implemented on Layer 3, like hardware encryption, and can considerably reduce bandwidth requirements to support IP Security (IPSec).
A transform set is a combination of up to three individual IPSec transforms designed to implement a specific security policy to protect a particular data- flow. The transform sets represent the security choices available during IPSec SA negotiation between two IPSec peers in IKE Phase 2 quick mode. The following are two examples of transform sets:
ah-sha-hmac and esp-des and esp-sha-hmac AH protocol with SHA-1 authentication, ESP DES encryption, plus ESP SHA-1 authentication.
esp-3des and esp-md5-hmac ESP protocol with DES encryption, plus ESP MD5 authentication.
The IKE Phase 2 quick mode operates much like the Phase 1 negotiation. The initiator sends one or more transform sets to the destination peer. The destination peer compares them in order against its own preferred transform sets. If a match is found, the destination peer returns the transform to the initiator peer to complete the “negotiation.” The peers must share a common transform set or the exchange can’t occur. If the peers can’t agree on a transform set, this means one or the other will need to configure a matching set of policies.
Transform sets are limited to three transforms with no more than one AH transform, plus no more than two ESP transforms. Transform sets combine the following IPSec features:
Payload authentication, example: AH transform
Payload encryption, example: ESP transform
IPSec mode (transport or tunnel)
You can define multiple transform sets, and then specify one or more of these sets using a crypto map entry. Use the global crypto ipsec transform-set command to define a transform set. Use the no form of the command to delete a transform set. The command syntax is as follows:
Rtr1(config)#crypto ipsec transform-set transform-set-name trans1 [trans2 [trans3]]
Rtr1(config)#no crypto ipsec transform-set transform-set-name
The command invokes the Crypto-Transform Configuration mode that can be used to define up to four transform sets. Use the exit command to end the configuration. Once defined, the transform sets can be specified in a crypto map entry. The following example shows the creation of four transform sets:
Rtr1#conf t Rtr1(config)#crypto ipsec transform-set MD5-DES esp-md5-hmac esp-des Rtr1(cfg-crypto-trans)#crypto ipsec transform-set DES-ONLY esp-des Rtr1(cfg-crypto-trans)#crypto ipsec transform-set AH-ONLY ah-sha-hmac Rtr1(cfg-crypto-trans)#crypto ipsec transform-set CPU-HOG ah-md5-hmac ?esp-md5-hmac esp-des Rtr1(cfg-crypto-trans)#exit Rtr1(config)#
When IKE isn’t being used to establish SAs, a single transform set must be configured and the transform set isn’t negotiated.
IPSec security associations that use the shared secret keys time out together, based on the SA lifetime configured. This section looks at configuring a global lifetime value to be used when a particular crypto map entry doesn’t have lifetime values configured. When a router receives a negotiation request from a peer, it uses the smaller of the lifetime value proposed by the peer or the locally configured global lifetime value for the new security associations.
Two lifetimes exist—a “timed” lifetime and a “traffic-volume” lifetime that can be configured. The SA and keys expire when the first of these lifetimes expires.
Any changes made to a global lifetime are only applied when the crypto map entry doesn’t have a lifetime value specified. The change isn’t applied immediately to existing security associations, but will be used in subsequent SA negotiations.
Use the global crypto ipsec security-association lifetime command to set the global lifetime. For a timed lifetime, use the seconds form of the command. The kilobytes form causes the security association to time out after the specified traffic limit (in kilobytes) has been protected. The lifetime values are ignored for manually established security associations installed using an ipsec-manual crypto map command entry. To reset a lifetime to the default value, use the no form of the command. The command syntax is as follows: