28-4
User Guide for Cisco Security Manager 4.4
OL-28826-01
Chapter 28 Group Encrypted Transport (GET) VPNs
Understanding the GET VPN Registration Process
2. Group members exchange IP packets that are encrypted using IPsec. Only the group members are
an active part of the VPN.
3. As needed, the key server pushes a rekey message to the group members. The rekey message
contains new IPsec policy and keys to use when old IPsec security associations (SAs) expire. Rekey
messages are sent in advance of the SA expiration time to ensure that valid group keys are always
available.
GET VPN is provisioned using Security Manager with the following caveats:
•GET VPN-aware VRF is not supported.
•DMVPN with GET is not supported, because there is no way to define DMVPN without tunnel
protection in Security Manager.
•Manual configuration of a group member to join a multicast group (ip igmp join-group) is not
supported. Security Manager only provisions static source-specific multicast (SSM) mappings.
Related Topics
•Understanding the GET VPN Registration Process, page 28-4
•Understanding the GET VPN Security Policy and Security Associations, page 28-10
•Configuring GET VPN, page 28-12
Understanding the GET VPN Registration Process
In GET VPN, group members comprise the VPN topology. Traffic in the VPN is traffic between group
members. For a device to become a group member, the device must successfully register with a key
server. Key servers maintain the security association (SA) policy and create and maintain the keys for
the group. When a group member registers, the key server downloads the policy and the keys to the group
member. The key server also rekeys the group before existing keys expire.
The key server has two responsibilities: servicing registration requests and sending rekeys. A group
member can register at any time and receive the most current policy and keys. When a group member
registers with the key server, the key server verifies the group ID that the group member is attempting to
join. If the group ID is valid, the key server sends the security association policy to the group member.
After the group member acknowledges that it can handle the downloaded policy, the key server
downloads the respective keys.
Communication among the key server and group members is encrypted and secured using two types of
keys: the traffic encryption key (TEK) and the key encryption key (KEK). The TEK is downloaded by
the key server to all the group members. The downloaded TEK is used by all the group members to
communicate securely among each other. This key is essentially the group key that is shared by all the
group members. The group policies and IPsec SAs are refreshed by the key server using periodic rekey
messages to the group members. The KEK is also downloaded by the key server and is used by the group
members to decrypt the incoming rekey messages from the key server.
The key server sends out rekey messages either because of an impending IPsec SA expiration or because
the security policy has changed on the key server. A rekey can also happen if the KEK timer has expired
(the key server sends out a KEK rekey). Rekey messages might also be retransmitted periodically to
account for possible packet loss. If the rekey mechanism is multicast, there is no efficient feedback
mechanism by which receivers can indicate that they did not receive a rekey message, so retransmission
seeks to bring all receivers up to date. If the rekey mechanism is unicast, the receivers send an
acknowledgment message.