28-7
User Guide for Cisco Security Manager 4.4
OL-28826-01
Chapter 28 Group Encrypted Transport (GET) VPNs
Understanding the GET VPN Registration Process
Fortunately, it is possible to mix multicast and unicast in a single GET VPN topology so long as all key
servers support multicast. When deciding which transport mechanism to use, consider the following
recommendations:
•If all key servers and group members, and the network, support multicast, use multicast.
•If all of the key servers and most of the group members support multicast, but a small number of
group members do not support multicast, use multicast. Group members that do not support
multicast will not receive rekey and IPsec SA updates. However, when the lifetime settings for these
items are about to expire, unicast group members will reregister with the key server and obtain the
new keys and IPsec SAs.
•If no group members, or only a few, support multicast, use unicast. The group members will then
receive rekeys and IPsec SA updates from the key server and not need to reregister to get them.
Related Topics
•Understanding the GET VPN Registration Process, page 28-4
•Generating and Synchronizing RSA Keys, page 28-13
•Configuring GET VPN, page 28-12
Configuring Redundancy Using Cooperative Key Servers
The key server is the most important entity in the GET VPN network because the key server maintains
the control plane. Therefore, a single key server is a single point of failure for an entire GET VPN
network. Because redundancy is an important consideration for key servers, GET VPN supports multiple
key servers, called cooperative (COOP) key servers, to ensure seamless fault recovery if a key server
fails or becomes unreachable.
You can configure a group member to register to any available key server from a list of all COOP key
servers. The group member configuration determines the registration order (see Configuring GET VPN
Group Members, page 28-20 and Edit Group Member Dialog Box, page 28-21). The key server defined
first is contacted first, followed by the second defined key server, and so on. It is a best practice to
distribute group member registration to all available COOP key servers to reduce the IKE processing
load on a single key server. Note that only the primary key server sends rekey messages.
When COOP key servers boot, all key servers assume a secondary role and begin an election process.
One key server, typically the one having the highest priority, is elected as a primary key server. The other
key servers remain in the secondary state. The primary key server is responsible for creating and
distributing group policies to all group members and to periodically synchronize the COOP key servers.
Cooperative key servers exchange one-way announcement messages (primary to secondary). If a
secondary key server does not hear from the primary key server for a certain length of time, the
secondary key server tries to contact the primary key server and request updated information. If the
primary key server does not respond, or if the secondary key server does not hear from the primary key
server, a COOP key server reelection is triggered and a new primary key server is elected.
Up to eight key servers can be defined as COOP key servers, but more than four COOP key servers are
seldom required. Because rekey information is generated and distributed from a single primary key
server, the advantage of deploying more than two key servers is the ability to handle registration load in
case of a network failure and reregistration taking place at the same time. This is especially important
when using Public Key Infrastructure (PKI) group member authorization because IKE negotiation using
PKI requires a lot more CPU power compared to IKE negotiation using pre-shared keys (PSKs).