IKE Overview

The IKE suite of protocols allows a pair of security gateways to:

IKE is based on the Oakley and Skeme key determination protocols and the ISAKMP framework for key exchange and security association establishment. IKE provides:

IKE is layered on UDP and uses UDP port 500 to exchange IKE information between the security gateways. Therefore, UDP port 500 packets must be permitted on any IP interface involved in connecting a security gateway peer.

The following sections expand on the IKE functionality available for the router.

Main Mode and Aggressive Mode

IKE phase 1 negotiations are used to establish IKE SAs. These SAs protect the IKE phase 2 negotiations. IKE uses one of two modes for phase 1 negotiations: main mode or aggressive mode. The choice of main or aggressive mode is a matter of tradeoffs. Some of the characteristics of the two modes are:

The next section describes aggressive mode in more detail.

Aggressive Mode Negotiations

During aggressive mode phase 1 negotiations, the E Series router behaves as follows:

Table 21 outlines the possible combinations of initiator proposals and policy rules. As indicated, allowing aggressive mode in a policy rule allows negotiation to take place no matter what the initiator requests.

Table 21: Initiator Proposals and Policy Rules

Aggressive Mode Setting

Initiator Requests (First Time)

Initiator Requests (Rekeyed)

Responder Policy


Main mode

Follows First Time

Aggressive or Main modes (follows initiator)


Aggressive mode

Follows First Time

Aggressive or Main modes (follows initiator)


Aggressive mode

Aggressive Mode

Aggressive mode


Main mode

Main Mode

Main mode

The router responds to phase 1 negotiations with the highest-priority policy rule that matches the initiator. A match means that all parameters, including the exchange type, match.

IKE Policies

An IKE policy defines a combination of security parameters to be used during the IKE SA negotiation. IKE policies are configured on both security gateway peers, and there must be at least one policy on the local peer that matches a policy on the remote peer. Failing that, the two peers are not able to successfully negotiate the IKE SA, and no data flow is possible.

IKE policies are global to the router. Every ISM on a router uses the same set of policies when negotiating IKE SAs. The agreed-on IKE SA between the local system and a remote security gateway may vary, because it depends on the IKE policies used by each remote peer. However, the initial set of IKE policies the router uses is always the same and independent of which peer the router is negotiating with.

During negotiation, the router might skip IKE policies that require parameters that are not configured for the remote security gateway with which the IKE SA is being negotiated.

You can define up to ten IKE policies, with each policy having a different combination of security parameters. A default IKE policy that contains default values for every policy parameter is available. This policy is used only when IKE policies are not configured and IKE is required.

The following sections describe each of the parameters contained in an IKE policy.


Priority allows better (more secure) policies to be given preference during the negotiation process. However, every IKE policy is considered secure enough to secure the IKE SA flow.

During IKE negotiation, all policies are scanned, one at a time, starting from the highest-priority policy and ending with the lowest-priority policy. The first policy that the peer security gateway accepts is used for that IKE session. This procedure is repeated for every IKE session that needs to be established.


A specific encryption transform can be applied to an IKE policy. The supported encryption algorithms are:

Hash Function

A specific hash function can be applied to an IKE policy. The supported ones are:

IKE also uses an authentication algorithm during IKE exchanges. This authentication algorithm is automatically set to the HMAC version of the specified hash algorithm. Therefore, you cannot have the hash function set to MD5 and the authentication algorithm set to HMAC-SHA.

Authentication Mode

As part of the IKE protocol, one security gateway needs to authenticate the other security gateway to make sure that the IKE SA is established with the intended party. The ERX router supports two authentication methods:

Diffie-Hellman Group

An IKE policy must specify which Diffie-Hellmann group is used during the symmetrical key generation phase of IKE. The following Diffie-Hellmann groups are supported:


Like a user SA, an IKE SA does not last indefinitely. Therefore, the router allows you to specify a lifetime parameter for an IKE policy. The timer for the lifetime parameter begins when the IKE SA is established using IKE.

IKE SA Negotiation

As the initiator of an IKE SA, the router sends its IKE policies to the remote peer. If the peer has an IKE policy that matches the encryption, hash, authentication method, and Diffie-Hellmann group settings, the peer returns the matching policy. The peers use the lesser lifetime setting as the IKE SA lifetime. If no match is found, the IKE SA fails, and a log alarm is generated.

As the responder of an IKE negotiation, the router receives all IKE policies from a remote security gateway. The router then scans its own list of IKE policies to determine whether a match exists, starting from the highest priority. If it finds a match, that policy is successfully negotiated. Again, the lifetime is negotiated to the lesser of the two lifetimes, and failures are logged.

Generating Private and Public Key Pairs

When any of the public key methods for authenticating remote security gateways is used, the system must have at least one valid pair of public or private keys. Therefore, the system provides a facility by which it can generate public and private key pairs for itself.

The private key is used only by the system itself. It is never exchanged with any other nodes. When generated, the private key is securely stored internally to the system in nonvolatile memory. Access to the private key is never given, not even to a system administrator or to a network management system.

The public key is used in either of the following scenarios:

The public/private key pair as provided by the system supports the RSA standard (512, 1024, or 2048 bits).

The public/private key pair is a global system attribute, regardless of how many ISMs exist in the system. Only one set of keys is available at any given time.