Setting Ike Policies - Brocade Communications Systems RFS6000 System Reference Manual

8. Select an existing entry and click the Delete button to remove it.
9. If the properties of an existing peer IP address and key are no longer relevant and cannot be

Setting IKE Policies

Each IKE negotiation is divided into two phases. Phase 1 creates the first tunnel (protecting later
IKE negotiation messages) and phase 2 creates the tunnel protecting the data. To define the terms
of the IKE negotiation, create one or more IKE policies. Include the following:
•
•
•
•
•
If IKE policies are not defined, the switch uses the default policy (with a default priority of 10001)
and contains the default values. When IKE negotiations begin, the peer initiating the negotiation
sends its policies to the remote peer. The remote peer searches for a match with its own policies
using the defined priority scheme.
Brocade Mobility RFS4000, RFS6000, and RFS7000 System Reference Guide
53-1002515-01
edited, click the Add button to create a new pre-shared key
a. Select the Peer IP Address checkbox to associate an IP address with the specific tunnel
used by a group of peers or, select the Distinguished Name checkbox to configure the
switch to restrict access to those peers with the same distinguished name, or select the
Hostname checkbox to allow shared-key messages between corresponding hostnames.
b. Define the Key (string ID) a remote peer uses to look up the pre-shared to interact securely
with peers within the tunnel.
c. Refer to the Status field for the current state of requests made from applet. This field
displays error messages if something is wrong in the transaction between the applet and
the switch.
d. Click OK to use the changes to the running configuration and close the dialog.
e. Click Cancel to close the dialog without committing updates to the running configuration.
An authentication scheme to ensure the credentials of the peers
An encryption scheme to protect the data
A HMAC method to ensure the identity of the sender, and validate a message has not been
altered
A Diffie-Hellman group establishing the strength of the of the encryption-key algorithm.
A time limit for how long the encryption key is used before it is replaced.
6
395