Filter
Top Products
28-11
User Guide for Cisco Security Manager 4.4
OL-28826-01
Chapter 28 Group Encrypted Transport (GET) VPNs
Understanding the GET VPN Security Policy and Security Associations
• Key server security policies and security associations—When you configure the Group
Encryption Policy for the GET VPN, as described in Defining GET VPN Group Encryption,
page 24-51, you configure ACLs that identify the traffic that should be encrypted and protected in
the VPN.
The security policies on the key server are coupled with transform sets and other settings to define
security associations; two IPsec security associations (SAs) are actually configured for every rule
within the ACL, and these SAs define how the selected traffic should be encrypted. Thus, all group
members use the same group SAs and they do not need to negotiate them with each other.
Because the key server policy is appended to the group member policy, the policy might be as simple
as permit ip any any, that is, encrypt all traffic that has not been excluded by the group member
policy.
However, you can create more complex sets of security policies and associations, setting up several
separate ACL policy objects that are coupled to different transform sets to define different types of
encryption.
If you create more than one security association, you must identify their order, and they are
appended to the group policy in that order. Remember, the end result is a single ACL, so if you
include a deny statement in the first ACL, any permit rules for the same traffic in subsequent security
associations are ignored, and the traffic is sent in clear text rather than being encrypted.
Note When you consider the security associations defined in the Group Encryption Policy as a
whole, you can define up to 100 ACL permit entries. Each permit entry results in a pair of
IPsec SAs; the maximum number of IPsec SAs in a group can not exceed 200. It is a best
practice to summarize interesting traffic to as few permit entries as possible, and to build
symmetric policies, where the source and destination addresses are the same. Unlike
traditional IPSec policies, where source and destination address ranges must be uniquely
defined, GET VPN is optimized when the source and destination address range are the same.
If you configure a rule that has different source and destination addresses, you must also
configure the mirrored rule (where the source and destination address are flipped), meaning
that four SAs are consumed.
In addition to these security policies, there is an additional fail-close ACL that influences traffic patterns
if you configure fail-close mode on a group member. For a complete discussion, see Configuring
Fail-Close to Protect Registration Failures, page 28-8.
Related Topics
• Configuring GET VPN, page 28-12
• Creating Access Control List Objects, page 6-49
• Creating Extended Access Control List Objects, page 6-50
Understanding Time-Based Anti-Replay
Anti-replay is an important feature in a data encryption protocol such as IPSec (RFC 2401). Anti-replay
prevents a third party from eavesdropping on an IPsec conversation, stealing packets, and injecting those
packets into a session at a later time. The time-based anti-replay mechanism helps ensure that invalid
packets are discarded by detecting the replayed packets that have already arrived at an earlier time.