Table Of Contents
Defining IKE Policies
Understanding IKE Policies
Deciding Which Encryption and Hash Algorithms to Use
Deciding Which Authentication Method to Use
Default IKE Policies in Router MC
Working With IKE Policies
Viewing Existing IKE Policies
Creating an IKE Policy
Accessing the IKE Policy Wizard
Naming the IKE Policy
Selecting Algorithms
Defining IKE Policy Parameters
Viewing a Summary of the IKE Policy
Editing an IKE Policy
Deleting an IKE Policy
Defining Authentication Parameters
Defining Preshared Key Parameters
Using Router MC for Preshared Key Management Only
Creating Group Preshared Keys
Defining Passive IPSec
Managing CA Enrollment
Defining CA Parameters
Defining IKE Policies
Internet Key Exchange (IKE) is the facilitator and manager of IPSec-based communications. It is a hybrid protocol used to authenticate IPSec peers, negotiate and distribute encryption keys, and automatically establish IPSec security associations (SAs).
The following topics provide information about defining IKE policies in Router MC:
•
Understanding IKE Policies
•Working With IKE Policies
•Defining Authentication Parameters
•Defining Passive IPSec
Understanding IKE Policies
An IKE policy defines a combination of security parameters to be used during IKE negotiation. When the IKE negotiation begins, the peer that initiates the negotiation sends all its IKE policies to the remote peer. The remote peer looks for a policy match by comparing its own policies against the policies received from the initiating peer.
A match is made when policies on both sides contain the same encryption, hash, authentication, and Diffie-Hellman parameter values. If there is more than one policy match, the policy with the highest position in the list is used, because it has highest priority. If no acceptable match is found, IKE refuses negotiation and IPSec communication will not be established. If a match is found, IKE will complete negotiation, and IPSec security associations will be created.
In general, you should be aware of the capabilities and limitations of your devices for supporting different algorithms, and you should cover all the possible options by defining different IKE policies.
IKE Policies in Router MC
Router MC enables you to define IKE policies on multiple devices, rather than having to define them on each device individually. Using Router MC, you can define IKE policies that specify:
•Which encryption algorithm to use for the IPSec negotiation, either 56-bit DES-CBC (DES) or 3DES.
•Which hash algorithm to use for integrity checking, either SHA or MD5.
•Which Diffie-Hellman group to use to operate the encryption algorithm.
•Which device authentication method to use, either Preshared Key or RSA Signature.
•For how long the IKE SA will be valid.
Note Router MC provides a default IKE policy that is defined on the Global object. The default IKE policy uses 3DES, SHA, Diffie-Hellman group 2, and preshared key.
The following topics will help you decide which algorithms and authentication method best meet your needs:
•Deciding Which Encryption and Hash Algorithms to Use
•Deciding Which Authentication Method to Use
Deciding Which Encryption and Hash Algorithms to Use
When deciding which encryption and hash algorithms to use for the IKE policy, your choice is limited to algorithms that are supported by both peers in a VPN connection. There is also often a trade-off between security and performance when choosing one algorithm over another. Therefore, you should evaluate the level of your network's security risks and your tolerance for these risks.
Encryption Algorithm
You have the following options for encryption algorithm: DES, 3DES, and AES.
•DES (Data Encryption Standard) is a symmetric secret-key block algorithm. It is faster than 3DES and uses less system resources, but it is also less secure. If you do not need strong data confidentiality, and if system resources or speed is a concern, you should choose DES.
•3DES (Triple DES) is more secure because it processes each block of data three times, each time with a different key. However, it uses more system resources and is slower than DES. 3DES is the recommended encryption algorithm, assuming that the devices support it.
•AES (Advanced Encryption Standard) provides greater security than DES and is computationally more efficient than 3DES. AES offers three different key strengths: 128-, 192- and 256- bit keys. AES is only supported on devices with IOS 12.2(13)T and higher.
Note AES cannot be used in conjunction with a hardware encryption card.
Hash Algorithm
You have two options for hash algorithm: SHA and MD5.
•SHA produces a 160-bit digest, and is more resistant to brute-force attacks than MD5. However, it is also more resource intensive than MD5. For implementations that require the highest level of security, use the SHA hash algorithm.
•MD5 produces a 128-bit digest, and uses less processing time for an overall faster performance than SHA, but is considered to be weaker than SHA.
Modulus Group
Router MC supports Diffie-Hellman group 1, group 2, and group 5 key derivation algorithms. Each group has a different size modulus:
Group 1: 768-bit modulus.
Group 2: 1024-bit modulus.
Group 5: 2048-bit modulus.
A larger modulus provides higher security, but requires more processing time. Therefore, use Group 1 on low-end routers and Group 2 or 5 on high-end routers. You must have a matching modulus group on both peers.
See Selecting Algorithms.
Deciding Which Authentication Method to Use
Router MC currently supports two methods for peer device authentication in a VPN communication: preshared key and RSA Signature.
Preshared Key
Preshared keys allow for one or more peers to use individual shared secrets to authenticate encrypted tunnels. A preshared key must be configured on each participating peer. Distribution of this preshared key usually takes place through a secure out-of-band channel. IKE peers authenticate each other by computing and sending a keyed hash of data that includes the preshared key. If the receiving peer is able to independently create the same hash using its preshared key, then it knows that both peers must share the same secret, thus authenticating the other peer. If one of the participating peers is not configured with the same preshared key, the IKE SA cannot be established.
Router MC enables you to define unique preshared keys by manually specifying the required key or automatically, in which case Router MC automatically generates a new preshared key per VPN connection.
Manually-defined preshared keys are more appropriate for smaller networks. In larger VPNs, assigning unique preshared keys to each device pair becomes unwieldy and updating the preshared keys becomes more difficult. In addition, if many peer-to-peer connections use the same preshared key, security can be compromised. Therefore, either use the automatic preshared key generation feature or define preshared keys on individual devices or small device groups, rather than globally or on large subsets of your device inventory.
See Defining Preshared Key Parameters.
RSA Signature
RSA Signature is an authentication method in which RSA key pairs are used to sign and encrypt IKE key management messages. RSA Signature provides non-repudiation of communication between two peers, meaning that it can be proved that the communication actually took place.
When RSA Signature is used as the authentication method, the peers are configured to obtain digital certificates from a Certification Authority (CA). CAs are responsible for managing certificate requests and issuing certificates to participating IPSec network devices. These services provide centralized key management for the participating devices.
While the use of preshared keys does not scale well, using a CA can dramatically improve the manageability and scalability of your IPSec network. With a CA, you do not need to configure keys between all of the encrypting devices. Instead, each participating device is registered with the CA, and requests a certificate from the CA. Each device that has its own certificate and the public key of the CA can authenticate every other device within a given CA's domain.
Note If you select RSA Signature for a Router MC IKE policy, or if your device was previously configured with RSA Signature, you must deploy configurations directly to your device, not to a file.
See Defining CA Parameters for more information.
Default IKE Policies in Router MC
Router MC provides various default policies for your convenience, including a predefined IKE policy. If it meets your requirements, you can use the predefined policy instead of having to create your own IKE policy.
The predefined IKE policy has the following parameters:
•Encryption algorithm—3DES
Note Before using the default IKE policy, make sure that your routers support 3DES. If not, you can change the encryption algorithm to DES by editing the default policy on the Global level.
•Hash algorithm—SHA
•Modulus Group—2
•Default lifetime—86400 seconds
•Authentication method—auto-generated preshared keys.
You can edit the predefined IKE policy, as required. You can also delete the policy (if Global is selected in the Object Selector).
Working With IKE Policies
The following topics provide information about working with IKE policies in Router MC:
•Viewing Existing IKE Policies
•Creating an IKE Policy
•Editing an IKE Policy
•Deleting an IKE Policy
Viewing Existing IKE Policies
The IKE Policies page, accessed from the TOC in the IKE section of the Configuration tab, displays a list of all the IKE policies that have been defined on a particular object (global, device group or device), in table format. Each table row represents an IKE policy and each table column provides a different field of information for that policy. You can select a policy in the list to edit it, delete it, or change its position in the list.
Table 1-1 describes the fields and buttons in the IKE Policies page.
IKE policies are listed in the order that you define them. By default, policies that were inherited from higher level objects are placed at the bottom of the list. You can remove inherited policies from the list by deselecting the Inherited Policies check box. If you do this, the inherited policies will not be configured on the device and will not be considered during the IKE negotiation between the two peers.
When a device sends its IKE policies to a remote peer, the IKE policies are scanned until a match between the two peers is found. If there is more than one match, the policy that is highest in the list has priority. You can change the order of the policies using the Move Up and Move Down buttons.
Table 1-1 describes the elements in the IKE Policies page.
Table 1-1 IKE Policies—GUI Reference
GUI Element
|
Description
|
Inherit default policies check box
|
This check box is present if an object other than Global is selected in the Object Selector. If this check box is selected, IKE policies will be inherited from the parent group and displayed in the list of IKE policies. If you do not want these policies to be configured on the device, deselect the check box. This removes the inherited policies from the list and only the IKE policies defined on the selected object will be configured on the device and considered during IKE negotiation.
|
# column
|
Sequentially numbers the IKE policies in the list.
|
Check box column
|
Enables you to select an IKE policy to edit it, delete it, or change its position in the list. You can select more than one check box at a time for deletion. Inherited policies have no check box and can only be managed on the object on which they were created.
|
Name column
|
Displays the name of the IKE policy.
|
Defined On Column
|
Displays the object on which the IKE policy was defined.
|
Encryption Column
|
Displays the encryption algorithm that the policy uses.
|
Hash Column
|
Displays the hash algorithm that the policy uses.
|
Modulus Group Column
|
Displays the Diffie-Hellman group that the policy uses.
|
Lifetime Column
|
Displays the lifetime of the IKE SA.
|
Authentication Column
|
Displays the authentication method used in the policy.
|
Rows per page list box
|
Enables you to change the number of policies displayed in the list.
|
Create button
|
Click to create a new policy.
|
Edit button
|
Click to modify the selected policy.
|
Move Up button
|
Click to move the selected policy one row up in the list. This increases the priority of the policy.
|
Move Down button
|
Click to move the selected policy one row down in the list. This decreases the priority of the policy.
|
Delete button
|
Click to delete the selected policy.
|
Creating an IKE Policy
You can create IKE policies at any level in the VPN object hierarchy (global, device group, or device). The policies will be inherited by all device groups and devices contained within the selected object. You can create new policies on the device group or device level to override inherited policies.
The following tips will help you decide on which level to define your IKE policies:
•IKE policies defined on the global level will be used for all communications between devices. After you have created the basic IKE policies for the VPN, you can create additional, overriding policies on the device group or device level. In this way, you can take into account the encryption and hash algorithms supported by the various devices, and the different levels of security needed for different communications channels.
•If you choose to use a manually specified preshared key (not automatically generated) as your authentication method, the IKE policy should be defined on a group of spokes that is a subset of your device inventory or on individual spokes. If you define the IKE policy on the global level, all the connections in the VPN use the same key, resulting in reduced security.
•If you use automatically generated preshared keys, you can define IKE policies on the global level, because Router MC generates a different key for every hub-spoke connection, thus ensuring security. When using automatically generated preshared keys, you must deploy to both the hub and the spoke so that Router MC can configure the keys symmetrically.
You create an IKE policy using the IKE Policy wizard. The following topics describe the tasks you perform to create an IKE policy using this wizard:
•Accessing the IKE Policy Wizard
•Naming the IKE Policy
•Selecting Algorithms
•Defining IKE Policy Parameters
•Viewing a Summary of the IKE Policy
Note The same IKE policy wizard pages are used for editing a policy, enabling you to modify values as required. See Editing an IKE Policy for more information.
After you have finished creating the IKE policy, you can define the credentials for the authentication methods used in your policies. See Defining Authentication Parameters for more information.
Accessing the IKE Policy Wizard
To access the wizard, complete the steps in this procedure.
Before You Begin
•In the Object Selector, select the object on which you want to create the policy.
•If workflow mode is enabled, make sure that you are working within the context of an open activity.
Procedure
Step 1 Select Configuration > IKE.
Step 2 Select IKE Policies from the TOC. The IKE Policies page appears. It contains a list of the IKE policies defined on the selected device or device group (if any).
Step 3 Click Create. The first page of the IKE Policy wizard appears.
Naming the IKE Policy
Router MC identifies each policy that you create by its name. After you have finished creating the policy, it is listed by this name in the IKE Policies page (see Viewing Existing IKE Policies for more information). Because the policy name also enables you to distinguish one policy from another for reviewing, editing, or deleting policies, you should assign a logical name that reflects the contents of the policy. You can also enter a description of the policy.
Procedure
Step 1 Enter a name and description in the fields provided. See Table 1-2 for descriptions of the fields.
Step 2 Click Next. The Algorithms page appears. Proceed to Selecting Algorithms.
Table 1-2 describes the elements in the IKE Policy Name and Comment page.
Table 1-2 IKE Policy Name—GUI Reference
GUI Element
|
Description
|
Name field
|
Enter a unique name for the IKE policy, for identification purposes.
|
Comment field
|
Enter a description of the policy.
|
Next button
|
Click to go to the next page in the wizard.
|
Cancel button
|
Click to exit the wizard without saving your settings.
|
Selecting Algorithms
The Algorithms page of the IKE Policy wizard enables you to select the encryption and hash algorithms and the Diffie-Hellman group for the policy. See Deciding Which Encryption and Hash Algorithms to Use for more information.
Procedure
Step 1 Select the required algorithms in the fields provided. See Table 1-3 for descriptions of the fields.
Step 2 Click Next. The Parameters page appears. Proceed to Defining IKE Policy Parameters.
Table 1-3 describes the elements in the Algorithms page.
Table 1-3 Algorithms—GUI Reference
GUI Element
|
Description
|
Encryption Algorithm list box
|
Select the required encryption algorithm for the policy:
•DES—A 56-bit symmetric secret-key block algorithm. DES is faster than 3DES and uses less system resources, but it is also less secure. If you do not need strong data confidentiality, and if system resources or speed is a concern, you should choose DES.
•3DES—A more secure algorithm that processes each block of data three times, each time with a different key. However, it uses more system resources and is slower than DES.
•AES—Provides greater security than DES and is computationally more efficient than 3DES. AES offers three different key strengths: 128-, 192- and 256- bit keys.
|
Hash Algorithm list box
|
Select the required hash algorithm for the policy:
•SHA—Produces a 160-bit digest, which is more resistant to brute-force attacks than MD5. However, it is also more resource intensive than MD5. For implementations that require the highest level of security, use the SHA hash algorithm.
•MD5—Produces a 128-bit digest, which uses less processing time for an overall faster performance than SHA, but is considered to be weaker than SHA.
|
Modulus Group list box
|
Select the required Diffie-Hellman group for the policy:
•Group 1—768-bit modulus.
•Group 2—1024-bit modulus.
•Group 5—2048-bit modulus.
The larger the modulus, the higher the security and the more processing time is required. Therefore, use Group 1 on low-end routers and Group 2 or 5 on high-end routers.
|
Back button
|
Click to go back to the previous page in the wizard.
|
Next button
|
Click to go to the next page in the wizard.
|
Cancel button
|
Click to exit the wizard without saving your settings.
|
Defining IKE Policy Parameters
The Parameters page of the IKE Policy wizard enables you to select the method to be used to authenticate the peers that wish to communicate, and to specify how long the IKE security association (SA) will exist before it expires.
Note Certain parameters must be defined for each authentication method. See Defining Authentication Parameters for more information.
Procedure
Step 1 Select the required authentication method and specify the lifetime of the IKE SA in the fields provided. See Table 1-4 for descriptions of the fields.
Step 2 If Summary appears in the TOC, click Next. The IKE Policy Summary page appears. Proceed to Viewing a Summary of the IKE Policy.
OR
If Summary does not appear in the TOC, click Finish to complete the creation of the IKE policy, or go back to a previous step in the wizard to change your definitions, as required.
Note The system might be set up to exclude summary pages from all wizards. See Defining System Settings, page 1-1 for more information.
Table 1-4 describes the elements in the IKE Policy Parameters page.
Table 1-4 IKE Policy Parameters—GUI Reference
GUI Element
|
Description
|
Lifetime field
|
Enter a value, in seconds, to determine how long the IKE SA will exist before it expires. The value can be between 60 and 86400 seconds. The default is 86400 seconds (one day).
The shorter the IKE SA lifetime, the more secure the IKE negotiation is likely to be. However, a longer IKE SA lifetime might save time when setting up IPSec SAs, because the IKE SA can be reused by subsequent IKE negotiations before it expires.
|
Authentication list box
|
Select the required authentication method for the policy:
•Preshared Key—Allows for one or more peers to use individual shared secrets to authenticate encrypted tunnels. A preshared key must be configured on each participating peer. If one of the participating peers is not configured with the same preshared key, the IKE SA cannot be established. If you choose the Preshared Key option, you must define the Preshared Key parameters. See Defining Preshared Key Parameters for more information.
•RSA Signature—Uses RSA key pairs to sign and encrypt IKE key management messages. When RSA Signature is used as the authentication method, the peers are configured to obtain digital certificates from a Certification Authority (CA). When using RSA Signature, you must deploy to live devices, not to files. If you choose the RSA Signature option, you must define CA parameters. See Managing CA Enrollment for more information.
See Deciding Which Authentication Method to Use if you are undecided about which authentication method to use.
|
Back button
|
Click to go back to the previous page in the wizard.
|
Next button
|
Available only if Summary appears in the TOC. The system might be set up to exclude summary pages from all wizards. See Defining System Settings, page 1-1 for more information.
Click to go to the next page in the wizard.
|
Finish button
|
Available only if Summary does not appear in the TOC. See Defining System Settings, page 1-1.
Click to complete the IKE policy creation or modification process and exit the wizard.
|
Cancel button
|
Click to exit the wizard without saving your settings.
|
Viewing a Summary of the IKE Policy
Note If the Show Summary Step in Wizards check box in the System Settings page is deselected, the Summary page is not available. See Defining System Settings, page 1-1.
The Summary page provides an overview of your IKE policy definitions for your verification. See Table 1-5 for a description of the fields and buttons in this page.
Procedure
Step 1 Verify that your IKE policy definitions are correct.
Step 2 Click Finish to complete the creation of the IKE policy or go back to a previous step in the wizard to change your definitions, as required.
Table 1-5 describes the elements in the IKE Policy Summary page.
Table 1-5 IKE Policy Summary—GUI Reference
GUI Element
|
Description
|
Summary of IKE Policy area
|
Lists all your definitions for the IKE policy.
|
Back button
|
Click to go back to the previous page in the wizard.
|
Finish button
|
Click to exit the wizard and complete the policy creation or modification process.
|
Cancel button
|
Click to exit the wizard without saving your settings.
|
Editing an IKE Policy
You can edit any existing IKE policy. Policy editing is done in the IKE Policy wizard that was used to create the policy. You can use the TOC to go directly to the page you want to edit.
Before You Begin
•In the Object Selector, select the object on which you want to create the policy.
•If workflow mode is enabled, make sure that you are working within the context of an open activity.
Procedure
Step 1 Select Configuration > IKE.
Step 2 Select IKE Policies from the TOC. The IKE Policies page appears.
Step 3 Select the check box next to the policy you want to edit and click Edit. The Name and Comment page of the IKE Policies wizard appears. It contains the name and comment for the selected policy.
Step 4 Select the required page from the TOC or click the Next button to move through the pages in the wizard. Each page shows the values that were defined for the selected IKE policy and you can edit them as required.
Step 5 Click Finish when you have finished editing the policy.
Deleting an IKE Policy
You can delete any existing IKE policy. You can delete multiple policies at one time.
Before You Begin
•In the Object Selector, select the object on which you want to create the policy.
•If workflow mode is enabled, make sure that you are working within the context of an open activity.
Procedure
Step 1 Select Configuration > IKE.
Step 2 Select IKE Policies from the TOC. The IKE Policies page appears.
Step 3 Select the check box next to each policy you want to delete and click Delete. The policy is deleted from the list of policies.
Defining Authentication Parameters
You must define parameters for each of the available authentication methods so that IKE and IPSec can use your IKE policies successfully. For preshared key, you can either enter a key manually, or have Router MC automatically generate a key per hub-spoke communication session.You can also define group preshared keys. For RSA Signature, you must define parameters for Certification Authority (CA) authentication and enrollment.
The following topics provide information about defining authentication parameters:
•Defining Preshared Key Parameters
•Creating Group Preshared Keys
•Managing CA Enrollment
Note The authentication parameters you define apply to all the IKE policies on the selected object. For example, if you have selected a device group and you define a preshared key, all IKE policies on all devices in that device group that use preshared key as the authentication method, will use the key you defined.
Defining Preshared Key Parameters
If you want to use preshared key as your authentication method, the peers that will be participating in VPN communications must be configured with a specific key that will be their shared secret for authenticating the connection. You can decide on a specific key to use, or you can let Router MC automatically allocate a random key to the participating peers. Router MC allocates a different key for each hub-spoke connection. Preshared keys are configured on spokes. Router MC mirrors the spoke's preshared key on its assigned hub.
If all the connections in a VPN use the same preshared key, security can be compromised. Therefore, it is advisable to use automatically generated keys.
Note You can set up Router MC to manage preshared keys only, and no other VPN or firewall policies. See Using Router MC for Preshared Key Management Only for more information.
When using preshared keys for authentication, there are three available methods for negotiating key information and setting up IKE SAs:
•Main mode address—Negotiation is based on IP address. Main mode provides the highest security since it has three two-way exchanges between the initiator and receiver.
•Main mode fully qualified domain name (FQDN)—Negotiation is based on DNS resolution, with no reliance on IP address. This option can only be used if the DNS resolution service is available for the host. It is useful when managing devices with dynamic IP addresses that have DNS resolution capabilities.
•Aggressive mode—Negotiation is based on IP address or host name (without DNS resolution), depending on what was provided for the host. Aggressive mode is less secure than main mode. However, it provides more security than using group preshared keys if the IP address of the VPN interface on the host is unknown, and the FQDN of the dynamic IP peer is not DNS resolvable. This is the recommended negotiation method to use in conjunction with a GRE Dynamic IP or DMVPN failover and routing policy. See Understanding GRE with DMVPN, page 1-6 for more information.
Note Router MC provides a default preshared key policy in which the keys are auto-generated, and main mode address is used for key negotiation.
Like IKE policies, preshared key parameters are specific to the object you selected in the Object Selector, and are inherited by lower level objects, unless you override them. For example, on the global level, you could specify a key to be used for all peer-to-peer connections initiated within the VPN. If you wanted to use a different key for one of your spokes, you could specify this key on the spoke. The key that you specify on the spoke level overrides the key specified on the global level and will be used for the peer-to-peer communications involving that spoke.
You can also create group (wildcard) keys on hubs or on groups containing hubs, to be used for dynamic crypto in cases where a spoke does not have a fixed IP address, as described in Creating Group Preshared Keys. However, in this case, all spokes connecting to the hub will have the same preshared key, which compromises security.
Note The default key size is 100. To change the key size, go to the following location on the Router MC server machine: \CSCOpx\MDC\iosmdc\config. Open iosmdc.cfg and change the KEY_SIZE parameter.
Before You Begin
•In the Object Selector, select the object on which you want to create the policy.
•If workflow mode is enabled, make sure that you are working within the context of an open activity.
Procedure
Step 1 Select Configuration > IKE.
Step 2 Select Preshared Key from the TOC. The Preshared Key page appears. See Table 1-6 for a description of the fields and buttons in this page.
Step 3 Select a radio button to indicate the type of preshared key you want to define, either automatically generated by Router MC or manually specified by you. For a manually defined preshared key, enter the key in the field provided.
Step 4 Select the radio button next to the required negotiation method.
Step 5 Click Apply to apply your definitions.
Table 1-6 describes the elements in the Preshared Key page.
Table 1-6 Preshared Key—GUI Reference
GUI Element
|
Description
|
Inherited Defaults (in the title bar)
|
Appears only if a device group or a specific device is selected in the Object Selector (not Global). Indicates that the displayed values were inherited from a higher level object. You have the option to override the inherited values, if desired.
|
Type radio buttons
|
•Select Fixed Key to use a static preshared key. Enter the required preshared key in the Key field that is only present when the Fixed Key radio button is selected. Note that all connections with the device groups and devices contained in the selected object will use this shared key. This could lead to reduced security.
•Select Auto-Generate to have Router MC automatically allocate a random key to the participating peers. This ensures security because Router MC generates a different key for every hub-spoke connection. The key is allocated during the first deployment to the devices and is used in all subsequent deployments to the same devices, until you check the Regenerate check box.
|
Regenerate check box
|
Only present if Auto-Generate is selected. If checked, Router MC generates a new key for the next deployment to the device(s). This is useful if there is a possibility that the secrecy of the keys might be compromised.
When you click Apply, the Regenerate check box is cleared. It does not remain checked because the new key will only be generated for the upcoming deployment, not for subsequent deployments (unless you check it again before the subsequent deployments).
|
Last Generation Time
|
The time of the last generation of a new key.
|
Negotiation Method radio buttons
|
Select the negotiation method to be used for exchanging key information:
•Select Main Mode Address if the IP address of the devices is known. Negotiation is based on IP address. Main mode provides the highest security since it has three two-way exchanges between the initiator and receiver.
•Select Main Mode FQDN if the IP address is not known and DNS resolution is available for the device(s). Negotiation is based on DNS resolution, with no reliance on IP address.
•Select Aggressive Mode if the IP address is not known and DNS resolution might not be available on the devices. Negotiation is based on IP address or host name (without DNS resolution), depending on what was provided for the host. Use aggressive mode with a GRE and DMVPN failover and routing policy, unless direct spoke to spoke tunneling is enabled (see Understanding GRE with DMVPN, page 1-6).
See Defining Preshared Key Parameters for more information.
|
Message and link to enable or disable management of preshared keys only (located at the bottom of the page)
|
You can use this to set up Router MC to manage only preshared keys (no other VPN policies) on the objects selected in the Object Selector. See Using Router MC for Preshared Key Management Only for more information.
Click the Click Here link to display a dialog box that contains information about working in this mode, and allows you to switch to managing preshared keys only.
After you have switched to this mode, the message changes and the Click Here link enables you to switch back to working with Router MC in the usual way.
|
Apply button
|
Click to apply your definitions.
|
Clear button
|
The Clear button is only present if Global is selected in the Object Selector. Click the Clear button to remove your current definitions.
|
Defaults button
|
The Defaults button is present when any object other than Global is selected in the Object Selector. Click to remove your local definitions and restore the inherited default values.
|
Using Router MC for Preshared Key Management Only
Router MC can be set up to manage only preshared keys on your devices, as opposed to managing preshared keys as part of your general IPSec configuration. When Router MC is set up to manage only preshared keys, Router MC only generates preshared key commands for the selected devices, even if there are other VPN policy definitions on those devices. Furthermore, you are not required to configure the basic settings and policies that would allow a VPN tunnel to be created (such as IKE policy, tunnel policy, and so on), before deploying to your devices.
Note When this option is in use, Router MC does not generate commands for VPN or firewall policies, other than preshared key. This applies to the spokes enabled with this option, as well as their assigned hubs.
To work with Router MC in preshared key only mode, all you need to do is define:
•The preshared key. See Defining Preshared Key Parameters.
•The hub assignment on the spokes. This is required so that Router MC can mirror the preshared key on the spoke's assigned hub. Go to Configuration > Settings > Spoke > Hub Assignment to define the hub assignment. See Specifying a Spoke's Hub Assignment, page 1-40.
•The VPN interface on the spokes. This is required so that the communicating peers can be identified. Go to Configuration > Settings > Spoke > VPN Interface to define the VPN interface. See Specifying a Spoke's VPN Interface, page 1-35.
Note In cases where some spokes are enabled with the preshared key only feature while others assigned to the same hub are not, the spokes enabled with this feature must be deployed separately from spokes without this feature.
To enable management of preshared keys only, follow the procedure below.
Before you Begin
•In the Object Selector, select the object on which you want to create the policy.
•If workflow mode is enabled, make sure that you are working within the context of an open activity.
Procedure
Step 1 Select Configuration > IKE.
Step 2 Select Preshared Key from the TOC. The Preshared Key page appears. See Table 1-6 for a description of the fields and buttons in this page.
Step 3 Click the Click Here link in the message relating to managing preshared keys only, located at the bottom of the Preshared Key page.
The Preshared Key Management Only dialog box appears. It provides information about the implications of setting up Router MC to manage only preshared keys, and requests your confirmation that you want to switch to this mode.
Step 4 Select the Yes radio button and click OK.
Creating Group Preshared Keys
Router MC enables you to create group (wildcard) preshared keys on a hub, to be used for communication with any device in a specified network, even if the IP address of the device is unknown. For example, a device that gets a dynamic IP address and configuration from the DHCP server on startup. If you can specify the network segment to which the device belongs, you can define a wildcard preshared key to be used if a device from the specified network segment initiates IKE negotiation. In such a case, a dynamic crypto map entry is created on the hub, and the remote peer's missing parameters are dynamically configured when the IKE and IPSec security associations are established.
Note When a group preshared key is configured on a hub, all the spokes connecting to that hub must be configured with a fixed preshared key that is identical to the group preshared key.
Note Group preshared key must be configured on the hub when GRE Dynamic IP is used for failover and routing.
Follow this procedure to create a new group preshared key.
Before You Begin
•In the Object Selector, select the object on which you want to create the policy.
•If workflow mode is enabled, make sure that you are working within the context of an open activity.
Procedure
Step 1 Select Configuration > IKE.
Step 2 Select Group Preshared Key from the TOC. The Group Preshared Key page appears. It lists the existing dynamic shared keys defined for the selected object. See Table 1-7 for a description of the fields and buttons in this page.
Step 3 Click Create. The Group Preshared Key dialog box appears.
Step 4 Identify the network and enter the required key in the fields provided. See Table 1-8 for descriptions of the fields. Click OK.
Step 5 Click Apply to apply your definitions. Your new dynamic shared key is added to the list of dynamic shared keys.
Table 1-7 describes the elements in the Group Preshared Key page.
Table 1-7 Group Preshared Key—GUI Reference
GUI Element
|
Description
|
Check box column
|
Enables you to select a group preshared key to edit or delete it. Inherited keys have no check box and can only be managed on the object on which they were created.
|
Key column
|
Shows the group shared key.
|
Network column
|
The network to which the initiating spoke must belong, in order for the dynamic shared key to be used.
Router MC does not support the entry of 0.0.0.0 as the network address because this can compromise network security. If you choose to use this IP address anyway, you must configure it using beginning or ending commands (see Entering Additional CLI Commands (Beginning and Ending Commands), page 1-46).
|
Rows per page list box
|
Enables you to change the number of policies displayed in the list.
|
Create button
|
Click to create a new group preshared key. See Create Group Preshared Key—GUI Reference for a description of the page that appears when you click the Create button.
|
Edit button
|
Click to modify the group preshared key.
|
Delete button
|
Click to delete the group preshared key.
|
Table 1-8 describes the elements in the Create Group Preshared Key dialog box.
Table 1-8 Create Group Preshared Key—GUI Reference
GUI Element
|
Description
|
Host/Network field
|
Specify the host name of the initiating spoke or the network to which the initiating spoke must belong, for the group shared key to be used. For the network, enter the IP address and subnet mask, for example, 172.168.10.20/255.255.255.0.
Note Router MC does not support the entry of 0.0.0.0 as the network address because this could compromise the security of the network. If you choose to use this address anyway, you must configure it using beginning or ending commands. See Entering Additional CLI Commands (Beginning and Ending Commands), page 1-46 for more information.
|
Key field
|
Enter the required key in the field.
|
OK button
|
Click to save your definitions and return to the Group Preshared Key page.
|
Cancel button
|
Click to exit without saving your definitions.
|
Defining Passive IPSec
Passive IPSec is an intermediate mode for IPSec that enables routers within an existing network to accept and transmit both encrypted and unencrypted data. In Passive IPSec mode, the router attempts to negotiate an encrypted session when sending data. If the peer is configured with IPSec, data will be encrypted. If not, data will be sent on the clear.
Passive IPSec is useful for phased introduction of IPSec into an existing network. As more devices are configured with IPSec, more data is encrypted.
Passive IPSec is supported on devices with IOS 12.2(13)T and above.
Follow this procedure to define passive IPSec.
Before You Begin
•In the Object Selector, select the object on which you want to create the policy.
•If workflow mode is enabled, make sure that you are working within the context of an open activity.
Procedure
Step 1 Select Configuration > IKE.
Step 2 Select Passive IPSec from the TOC. The Passive IPSec page appears. See Table 1-9 for a description of the fields and buttons in this page.
Step 3 Select the Use Passive IPSec check box to enable passive IPSec on the device(s).
Step 4 Specify a delay time in seconds that determines the time that packets can be sent unencrypted before another attempt is made to establish an encrypted IPSec connection.
Step 5 Click Apply.
Table 1-9 describes the elements in the Passive IPSec page.
Table 1-9 Passive IPSec—GUI Reference
GUI Element
|
Description
|
Use Passive IPSec check box
|
Select to enable passive IPSec mode so that the device will encrypt the data if the peer is configured with IPSec, or send it on the clear if there is no IPSec configuration on the peer.
If Passive IPSec was enabled on a parent object, deselecting this check box removes the inherited value.
|
Delay time field
|
Specify the time in seconds that packets can be sent unencrypted before another attempt is made to establish an encrypted IPSec connection. If no value is specified, the default of 300 seconds will be used.
|
Apply button
|
Click to apply your definitions.
|
Clear button
|
The Clear button is only present if Global is selected in the Object Selector. Click the Clear button to remove your current definitions.
|
Defaults button
|
The Defaults button is present when any object other than Global is selected in the Object Selector. Click to remove your local definitions and restore the inherited default values.
|
Managing CA Enrollment
When RSA Signature is used as the authentication method, the peers are configured to obtain digital certificates from a Certification Authority (CA). With a CA, you do not have to configure keys between all the encrypting routers. Instead, you individually enroll each participating router with the CA, requesting a certificate for the router. When this has been accomplished, each participating router can dynamically authenticate all the other participating routers.
CAs can also revoke certificates for devices that will no longer participate in IPSec. Revoked certificates are listed in a certificate revocation list (CRL), which each peer can check before accepting a certificate from another peer.
Router MC supports the Microsoft, Verisign and Entrust CAs.
Note Microsoft CA challenge passwords are only supported on devices with IOS 12.2(8)T and higher. If necessary, specify during Microsoft CA installation that challenge passwords should not be requested.
Certain prerequisites must be met to use a CA with Router MC. See Prerequisites for Successful CA Enrollment, page A-8 for more information.
What CA command types does Router MC support?
Router MC supports:
•Identity CAs, using the command crypto ca identity. An identity CA uses its own certificate to sign the certificate of a router, thereby validating the identity of the router. With identity CAs, both peering devices must use the same CA enrollment URL. Enrollment requests are interactive, therefore identity CA configurations can only be deployed to live devices.
•Trustpoint CAs (for devices with IOS 12.2(8)T and above), using the command crypto ca trustpoint. A trustpoint CA allows automatic enrollment requests for certificates. Enrollment is not interactive, therefore trustpoint CA policies can be deployed either to devices or to files (as long as you provide the CA authentication certificates manually rather than having Router MC get them from the CA enrollment URL). Trustpoint CAs allow for trusted peers, therefore, peering devices can use different CA enrollment URLs.
Options for Enrollment with the CA server
You can enroll with the CA server either directly, by specifying the HTTP URL of the server, or by means of a TFTP server.
The TFTP option is designed for users who do not have direct access to the CA server. It is only valid for devices with IOS 12.2(13)T and higher. On deployment, Router MC will generate the corresponding CA trustpoint command and authenticate command. The trustpoint command will be configured with the enrollment URL tftp://<tftpServer> <filename> entry to retrieve the CA certificate using TFTP.
Before using this option, you must make sure that the CA certificates file (.ca) is saved on the TFTP server. After deployment, you must transfer the certificate request generated by Router MC on the TFTP server to the CA, and then transfer the device's certificates from the CA to the device. See Prerequisites for Successful CA Enrollment, page A-8 for instructions.
Deployment of CA Policies
When a change is made to a device's CA policy and the device is selected for deployment, Router MC automatically includes all other devices that communicate with the selected device in the deployment so that they are updated with the policy change.
If there is any interactive element in either the CA authentication or enrollment process, CA policies can be deployed to live devices only, not to files. Router MC only supports deployment to files for trustpoint CAs for which you provide the CA authentication certificates by means of a manual cut and paste into the Router MC user interface. See Table 1-10 for more information about manual entry of CA certificates.
See Deploying Configurations, page 1-1 for more information about deployment options.
Defining CA Parameters
The CA manages certificate requests and issues certificates to the participating IPSec network devices. You must define CA parameters to determine how the CA is identified and how certificates are managed.
CA parameters can be defined on any level in the device hierarchy.
Follow this procedure to define CA parameters.
Before you Begin
•In the Object Selector, select the object on which you want to create the policy.
•If workflow mode is enabled, make sure that you are working within the context of an open activity.
Procedure
Step 1 Select Configuration > IKE.
Step 2 Select CA Parameters from the TOC. The CA Enrollment page appears.
Step 3 Enter information in the fields provided. See Table 1-10 for descriptions of the fields.
Step 4 Click Apply to apply your definitions.
Table 1-10 describes the elements in the CA Parameters page.
Table 1-10 CA Parameters—GUI Reference
GUI Element
|
Description
|
Enrollment Area
|
Allows you to define parameters for enrollment with the CA server.
|
CA URL and TFTP radio buttons
|
Select the CA URL radio button to enroll with the CA server directly.
Select the TFTP radio button to enroll with the CA server by means of a TFTP server, if you do not have direct access to the CA server.
The TFTP option is only available for devices with IOS 12.2(13)T and higher. It is grayed out if your selected object is a device with a lower IOS version. If your selected object is a device group, you will receive a validation warning during job generation for devices in the group running an IOS version below IOS 12.2(13)T.
|
Enrollment URL field
|
This field only appears when the CA URL radio button is selected.
Specify the URL of the CA to which your devices should send certificate requests.
The URL must be in the form of http://CA_name, where CA_name is the CA's host DNS name or IP address.
If the CA cgi-bin script location is not the default /cgi-bin/pkiclient.exe at the CA, you must also include the non-standard script location in the URL, in the form of http://CA_name/script_location, where script_location is the full path to the CA scripts.
|
Challenge Password check box
|
For Microsoft CA only. Enter the password by which the CA server will validate your identity.
The challenge password only relates to individual devices. This field is disabled if a device group is selected in the Object Selector.
Challenge passwords are only supported for devices that support trustpoint CAs (devices with IOS 12.2(8)T and higher). If you enter a challenge password for other devices, it will be ignored.
Note If you change the challenge password, you must re-enroll with the CA server by selecting the Re-enroll check box.
|
TFTP Server URL
|
This field only appears when the TFTP radio button is selected.
Enter the URL of the TFTP server to be used for transfer of certificate requests and certificates. The TFTP URL must start with tftp://
|
File Name
|
This field only appears when the TFTP radio button is selected.
Enter the name of the file that will store the trustpoint CA on the TFTP server, without an extension. The appropriate extension will be added by the system when necessary.
|
CA Name
|
Enter a name by which the CA will be identified. This name will also be used to generate the RSA key pair. If you leave this field blank, the fully qualified domain name (FQDN) will be used.
|
Retry Period field
|
Enter the wait period between certificate request retries, in minutes. The value can be between 1 and 60 minutes. The default is 1 minute.
|
Retry Count field
|
Specify how many times the device(s) will resend a certificate request if no certificate is issued upon the first request.
Enter a value between 1 and 100. The default is 10.
|
Include Router Serial Number check box
|
Indicate whether or not the router's serial number should be included in the obtained certificate. The serial number is used by the CA to either authenticate certificates or to later associate a certificate with a particular router. If you are in doubt, include the serial number, because it is useful for debugging purposes.
|
Re-enroll check box
|
Select to request new certificates from the CA server.
You must select this check box if you change the challenge password.
|
CA Certificates area
|
Allows you to define whether Router MC will retrieve the CA's certificates, directly from the CA server or you will provide the certificates manually.
|
Retrieve Using SCEP radio button
|
Select if you want Router MC to retrieve the CA's certificates from the CA server using Simple Certificate Enrollment Protocol (SCEP). Since this action is interactive, you will only be able to deploy the CA policy to live devices, not to files.
|
Enter Manually radio button
|
Select if you want to manually paste the CA's certificates into the Router MC user interface, after copying them from another device. When you select this radio button, a text field appears. Paste the certificates into the text field using your browser's Paste function, or the Ctrl-V keyboard shortcut.
You can paste up to three certificates into the text field. Each certificate must begin with the word "certificate" and end with the word "quit."
If you enter the certificates manually, you can deploy the CA policy to files (only for devices with IOS 12.2(8)T and higher).
|
CRL Checking area
|
Allows you to determine how Certificate Revocation Lists (CRLs) will be handled.
|
CRL list box
|
Select the CRL checking method to be used:
Optional: If a CRL exists on the device, it will be checked. The device will not actively download a CRL. If there is no CRL, all certificates will be allowed.
Best-Effort: The device will download the latest CRL from the specified LDAP server. If the download fails, certificates will be allowed. This option is only available for devices with IOS 12.2(8)T and higher.
Enabled (default): The device must check a CRL. If no CRL exists on the device, certificates will be denied and tunnel establishment cannot proceed.
|
LDAP Server URL
|
Specify the URL of the LDAP server from which the CRL can be downloaded. This URL must start with ldap://
|
Apply button
|
The Apply button is only present when Global is selected in the Object Selector because CA policies can only be defined globally for all devices. Click to apply your definitions.
|
Clear button
|
The Clear button is only present if Global is selected in the Object Selector. Click the Clear button to remove your current definitions.
|
Defaults button
|
The Defaults button is present when any object other than Global is selected in the Object Selector. Click to remove your local definitions and restore the inherited default values.
|
