Cisco Systems CL-28826-01 Security Camera User Manual


  Open as PDF
of 2616
 
28-6
User Guide for Cisco Security Manager 4.4
OL-28826-01
Chapter 28 Group Encrypted Transport (GET) VPNs
Understanding the GET VPN Registration Process
Decide whether to require authorization for group members to join the group. You can use certificate
authorization (which requires that you also configure the Public Key Infrastructure policy) or
preshared keys. Configuring authorization is required if the key server serves more than one group.
For information about the configuration options, see the Authorization Type setting described in
Defining GET VPN Group Encryption, page 24-51.
Related Topics
Generating and Synchronizing RSA Keys, page 28-13
Configuring GET VPN, page 28-12
Choosing the Rekey Transport Mechanism
When you configure the rekey settings in the Group Encryption Policy (as described in Defining GET
VPN Group Encryption, page 24-51), you must select whether to use multicast or unicast as the rekey
transport mechanism. The key server uses this method whenever sending new keys and IPsec security
associations (SAs) to group members or each other. There are advantages and disadvantages to each
method.
Multicast is the standard choice. Using multicast, the key server sends one copy of each rekey message
to all group members at once using a multicast group address, so there is no rekey delay and group
members can install the updated security policy essentially simultaneously (not accounting for regular
network delay). However, in some networks, multicast is either an extra cost feature, or it is simply not
allowed. If you configure multicast, you must supply the multicast address that will be used by the GET
VPN topology.
Unicast can be used when multicast is unavailable or undesirable. Using unicast, the key server sends
directed rekey and IPsec SAs to group members, and the group member sends an acknowledgment that
the message was received. Because unicast requires sending direct messages and receiving
acknowledgments, the key server sends the unicast messages to a subset of the group members at a time
(unless you have a relatively small VPN, perhaps fewer than 30 group members, in which case all group
members might be sent messages at the same time).
Thus, the relative benefits of multicast and unicast include the following:
With multicast, the key server does not know if a group member receives a message, whereas with
unicast, there are acknowledgments. With unicast, if the key server does not receive the
acknowledgment, it resends the message.
Multicast is faster than unicast, especially for large topologies with hundreds of group members.
Multicast rekey uses the same low CPU overhead whether there is one group member in the group
or a few thousand.
With unicast, if a group member continuously fails to send acknowledgments, the key server decides
the group member is no longer there and stops sending rekey messages. Thus, the key server always
has a list of active group members. The unresponsive group member must reregister to rejoin the
GET VPN topology. Because multicast does not use acknowledgments, the key server does not know
if a group member becomes unresponsive, and it does not maintain a list of active group members.
Tip To use multicast, you must enable multicast on the key servers and group members. Security Manager
does not provision these commands; it only enables multicast rekey, it does not enable the router to send
and receive multicast traffic. Therefore, you must manually enable multicast on the device, or use the
FlexConfig policy to provision the commands (see Creating FlexConfig Policy Objects, page 7-27).