28-8
User Guide for Cisco Security Manager 4.4
OL-28826-01
Chapter 28 Group Encrypted Transport (GET) VPNs
Understanding the GET VPN Registration Process
Tips
•The RSA key must be the same on all cooperative key servers. For information on synchronizing the
RSA key, see Generating and Synchronizing RSA Keys, page28-13.
•It is a best practice to enable periodic ISAKMP keepalives between key servers so that the primary
key server can track and display the state of the other secondary key servers. IKE Keepalives
between group members and the key server is not required and is not supported. For information on
configuring keepalives, see Configuring Global Settings for GET VPN, page28-16.
•The COOP protocol is configured on a per GDOI group basis. A key server that is configured with
multiple GDOI groups can maintain multiple unique COOP relationships with disparate key servers.
Configuring Fail-Close to Protect Registration Failures
Group members must register with the key server to become members of the GET VPN. Before a group
member successfully registers with the key server, traffic passing through the group member’s GET VPN
interface is not encrypted. The period of time in which clear-text transmissions occur can be short (if
registration succeeds) or potentially long, if the group member fails to register for any reason.
This default behavior is known as fail-open. If you consider it a violation of your security standards that
traffic is sent in clear text at any time, you can configure fail-close mode to protect traffic before (or
during) registration. With fail-close mode, all traffic on the interface is dropped except for the traffic you
specifically identify in the fail-close ACL. Fail-close mode essentially shuts down the interface until the
group member successfully registers with the key server and downloads the required keys and security
policy and associations. Note that the use of fail-close mode requires as a minimum Cisco IOS Software
release 12.4(22)T or 15.0; you can also configure it on all supported ASRs (see Understanding Devices
Supported by Each IPsec Technology, page 24-9).
Fail-close mode is used only during the initial registration. If a group member has already successfully
registered, the group member keeps the downloaded policy from the key server even if future
registrations fail. However, if you use the clear crypto gdoi command on the group member, the
subsequent registration attempt is considered a first-time attempt and fail-close mode is enforced.
You configure fail-close mode on the individual group members as described in Configuring GET VPN
Group Members, page 28-20. Thus, you can enable the mode on selected group members rather than on
all of them. You must specify a fail-close ACL to ensure that you do not lock yourself (and Security
Manager) out of the device, preventing configuration updates and maintenance until registration
succeeds.
The fail-close ACL is an extended ACL policy object and is configured as part of a crypto map on the
device. You configure the rules from the perspective of the group member. Use the following tips to help
you create an appropriate fail-close ACL:
•You can configure both permit and deny statements. In the fail-close ACL, “permit” means “do not
send this traffic,” whereas “deny” means “send this traffic in clear text.” This behavior is different
from that of the typical crypto map ACL, where the statements have the following meaning:
–
Permit—Means “encrypt this traffic.” Because the group member does not have the IPsec
security association required to encrypt the traffic prior to registration, the result is that the
traffic is dropped.
–
Deny—Means “do not encrypt this traffic.” In a typical crypto map ACL, a deny statement
results in the matching packet being compared to the next crypto map ACL configured on the
device (if any). However, if traffic matches a deny statement in the fail-close ACL, all crypto
map ACL processing ends and the traffic is allowed in clear text.