Configuring IPSec Using Pre-Shared Keys

20 Mar

Configuring IPSec Using Pre-Shared Keys
This section details how to configure IPSec on Cisco routers using pre-shared keys. Configuring IPSec encryption can be difficult and complicated. However, with a well-thought-out plan, the challenges associated with configuring IPSec can be overcome. Because IPSec can be configured without IKE (manual key configuration) or with IKE (pre-shared keys, public keys, or digital certificates), and the configuration of each is different, I will begin by configuring IPSec using IKE with pre-shared keys for authentication of IPSec sessions.

To configure IKE, perform the tasks in the following list. The first two tasks are required; the remaining tasks are optional:

1.The first step is to use the crypto isakmp enable command to enable IKE globally for the router. If you do not want IKE to be used with your IPSec implementation, use the no crypto isakmp enable command. IKE is enabled by default globally on the router and does not need to be enabled on a per−inter−faces basis.

2.The next step is to define a suite of IKE policies on the router. The IKE policies define the parameters to be used during IKE negotiation. Use the crypto isakmp policy <priority> command to uniquely identify and define the policy. The priority parameter assigns a priority to the policy and can accept any integer from 1 to 10,000, with 1 being the highest priority and 10,000 being the lowest priority. Multiple IKE policies can be configured for each peer participating in IPSec. Use of this command takes you into IKE policy configuration command mode (config−isakmp).

3.In IKE policy configuration command mode, use the encryption <des | 3des> command to define the encryption algorithm to be used for encryption of packets between IPSec peers. If this command is not defined within the IKE policy, the encryption algorithm defaults to 56−bit DES.

4.In IKE policy configuration command mode, use the hash <sha| md5> command to define the hash algorithm used within the IKE policy. If this command is not defined within the IKE policy, the hash algorithm defaults to SHA1.

5.To specify the authentication method used in the IKE policy, use this command in IKE policy configuration command mode:

authentication <rsa−sig | rsa−encr | pre−share>

If this command is not defined within the IKE policy, the authentication method defaults to RSA signatures.

6.To specify the Diffie−Hellman identifier used for the IKE policy, use the group <1 | 2> command in IKE policy configuration command mode. The group 1 command specifies that the policy should use the 768−bit Diffie−Hellman group. The group 2 command specifies that the policy should use the 1024−bit Diffie−Hellman group. If this command is not defined within the IKE policy, the 768−bit Diffie−Hellman group will be used.

7.To specify how long the IKE established security association should exist before expiring, use the lifetime <seconds> command in IKE policy configuration mode. If this command is not defined within the IKE policy, the security associations expire after 86,400 seconds or 1 day.

Note The default values for configured policies do not show up in the configuration when you issue a show running command. To view the default IKE values within the configured policies, use the show crypto isakmp policy command.

The configuration commands in the preceding list are all that are needed to enable and define the IKE policy. Next, you should define the ISAKMP identity for each peer that uses pre−shared keys in an IKE policy. When two peers use IKE to establish IPSec security associations, each peer sends its identity to the remote peer. To configure the ISAKMP identity mode used between peers, use the commands in the following steps:

1.Use this command to define the identity used by the router:

crypto isakmp identity <address|hostname>

The address parameter is used when there is only one interface and only one IP address that is used by the peer for IKE negotiations and the IP address is known. The hostname parameter is used if there is more than one interface that might be used for IKE negotiations or if the IP address is unknown. If this command is not specified, the identity parameter will be used by the router.

2.If the crypto identity was configured to use the hostname of the remote peer, the hostname of the remote peer must be defined using the ip host <name> <address> command to define a static hostname−to−address mapping in the host cache.

After configuring the ISAKMP identity used between peers, you must specify the pre−shared keys to use between each peer. The keys must be configured anytime pre−shared authentication is specified in an IKE policy. The same pre−shared key must be configured on each pair of IPSec peers when you’re using pre−shared keys for IKE authentication. Configuration of the pre−shared key can be accomplished by two separate commands and is dependant upon the identity configured in the previous command. Configure the pre−shared key using the following commands. To configure a pre−shared authentication key, use this command:

crypto isamkmp key key−string address <peer−address> −
<peer−mask>

This command is used if the ISAKMP identity was configured to use the address parameter or if the identity was not configured, because the default is to use the peer
routers address. If the ISAKMP identity was configured to use the hostname parameter, then use this command:

crypto isakmp key key−string hostname <peer−hostname>

The next task that needs to be performed is to configure the router for IPSec. The first step in configuring IPSec is to define the transform set the router should use. A transform set is an acceptable combination of security protocols, algorithms, and other settings to apply to IPSec−protected traffic. The transform set is agreed upon between peers during the IPSec security association negotiation. It tells the router how to protect data within a particular data flow. 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.

To define a transform set, use the following commands starting in global configuration mode (only the first command is required):

1.Define the transform set using the following command:

crypto ipsec transform−set transform−set−name <transform1>−
<transform2> <transform3>

Rules exist that define an acceptable combination of security protocols and algorithms that can be used as transforms. Table 6.1 defines the acceptable combinations.


1.To change the mode associated with the transform set, use the mode <tunnel | transport> command in crypto transport configuration mode. If this command is omitted, the mode will default to tunnel mode.

2.Note The IOS command parser will deny you from entering invalid combinations. There is one other possible transform, comp−lzs; however, it will not be discussed within this book.

After defining the transform set that IPSec should use, you must configure an access list. Access lists defined for IPSec are different than regular access lists, which permit or deny traffic from entering into or exiting out of an interface. Access lists are used with IPSec to define which IP traffic will be protected by encryption and which will not. To create access lists that define which traffic should be encrypted, use the following command in global configuration mode. To determine which IP packets will be encrypted by IPSec, use this command:

access−list access−list−number {deny | permit} <protocol> −
<source> <source−wildcard> <destination> <destination− −
wildcard> <log>

Cisco recommends that the access list keyword any be avoided when specifying the source address or destination address within the access list. It is not recommended because it causes the router to encrypt all outbound or all inbound traffic. Try to be as precise as possible when defining which packets to protect with an access list. It is also recommended that mirrored copies of the access list be configured between each host that is to perform IPSec.

After configuration of the access list(s), you must define IPSec crypto maps to allow the setup of security associations for traffic flows to be encrypted. Crypto map entries contain information for IPSec. When IKE is used to establish security associations, the IPSec peers can negotiate the settings they will use for the new security associations. This allows you to specify the parameters of the crypto map on a per−peer basis. To configure the crypto maps and define the appropriate parameters, use the commands in the following steps (only the first four steps are required):

1.To create the crypto map entry and enter the crypto map configuration mode, use this command:

crypto map map−name seq−num ipsec−isakmp

The map−name parameter defines the name that identifies the crypto map set. The seq−num parameter is the number that is assigned to this crypto map; it should not be
chosen arbitrarily because this number is used to rank multiple crypto map entries within a crypto map set, and a crypto map entry with a lower seq−num is evaluated before a map entry with a higher seq−num. Use of this command moves you into crypto map configuration mode. The ipsec−isakmp parameter specifies that IKE will be used to establish the security associations for protecting the traffic matched by this crypto map entry.

2.In crypto map configuration mode, use this command to specify an extended access list for a crypto map entry that matches packets that should be protected by encryption:

match address <access−list number | name>

3.To specify an IPSec peer, use the following command in crypto map configuration mode:

set peer <ip address| hostname>

You can specify the remote IPSec peer by its hostname if the hostname is mapped to the peer’s IP address in a domain name server (DNS) or if you manually map the hostname to the IP address with the ip host command that was discussed earlier. When using IKE to set up security associations, you can specify multiple peers per crypto map.

4.To specify which transform sets can be used with the crypto map entry, use this command:

set transform set <transform−set−name1> <transform−set− −
name2…transform−set−name6>

List multiple transform sets in order of priority with the highest−priority transform set listed first. When using IKE to set up security associations, you can specify multiple transform sets per crypto map.

5.Use the set pfs <group1 | group2> command to specify that IPSec should ask for perfect forward secrecy when requesting a new sa or should demand PFS in requests received from the IPSec peer.

6.To specify that separate IPSec security associations should be requested for each source/destination host pair, use the set security−association level per−host command. This command should be omitted if one security association should be requested for each crypto map access list permit entry.

7.To override the global lifetime value on a per−crypto−map−list basis, which is used when negotiating IPSec security associations, use this command:

set security−association lifetime <seconds seconds | −
kilobytes kilobytes>

After configuring the router for IPSec, the last step in IPSec configuration is to apply the configured crypto map to an interface. As soon as the crypto map is applied to an interface, the security associations are set up in the Security Association Database (SAD). Only one crypto map can be applied to an interface, and multiple crypto map entries with the same crypto name and different sequence numbers are permitted. To apply a previously defined crypto map set to an interface, use the commands in these steps:

1.To apply a previously defined crypto map to an interface, use the following command to move into interface configuration mode:

interface <interface type> <interface number>

2.To apply a previously defined crypto map set to an interface, use the crypto map map−name command. A crypto map set must be applied to an interface before that interface can provide IPSec services.

I’ll begin with the network shown in Figure 6.6. This network contains two routers, which must communicate with one another via the use of IPSec. Router A is the corporate gateway router and Router B is the branch office router for the remote location. Remote users communicate with the corporate office via the wide area network (WAN), and when users at the branch office communicate with the corporate office, their traffic should be protected with IPSec. This configuration will use all the security services provided by both IKE and IPSec, and Router A and Router B will be configured to exchange pre−shared keys.

Random Posts

No comments yet

Leave a Reply

You must be logged in to post a comment.