Cisco Systems CL-28826-01 Security Camera User Manual


  Open as PDF
of 2616
 
28-10
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
Understanding the GET VPN Security Policy and Security
Associations
GET VPN uses crypto map access control lists (ACLs) to identify the traffic that needs to be encrypted
in the VPN. These ACLs also identify traffic that should be sent as clear text instead of being encrypted
(essentially, traffic that lies outside of the VPN). The collection of these ACLs define the security policy
for the VPN.
GET VPN provides a multi-layered security policy. You define the general policy for the entire VPN on
the key server, but you can also define a separate security policy on group members to account for local
variations. The group member security policy always takes priority over the policy received from the key
server. When the group member registers with the key server, the group member downloads the key
server’s security policy and associations and the group member creates a new, single security policy
crypto map ACL by concatenating the individual security policies in this order: first, the group member’s
ACL; second, the key server’s first ACL; third, and so forth, any additional ACLs from the key server in
the order defined on the key server. It is important to understand that these merged ACLs are treated as
a single ACL; they are not searched as separate ACLs. Thus, if traffic matches a deny statement from the
group member’s ACL, that traffic is never tested against any ACL rules downloaded from the key server.
Tip If a group member leaves the GET VPN, the ACLs downloaded from the key server are removed, but the
group member security policy ACL is retained and remains configured on the device.
In GET VPN security policy ACLs (and crypto map ACLs in general), the permit and deny keywords
have special meaning:
Permit—Means “encrypt this traffic.” Permit entries are allowed only in the security policy ACLs
defined on the key server (in the Group Encryption Policy), because encrypted traffic needs to have
a full IPsec security association, which includes the transform set used for encrypting traffic, and
anti-replay and IPsec lifetime configurations. If a packet matches a permit entry, but no IPsec SA
exists for that packet, the packet is dropped.
Normally, your permit rules should be symmetric, that is, the source and destination addresses
should be the same. If you need to specify different source and destination addresses, you must
create two rules; the second rule should be a mirror image of the first rule, with the source and
destination address switched.
Deny—Means “do not encrypt this traffic.” In practice, this typically means that the traffic that
matches the deny statement is sent in the clear. However, if you configure other features that use
crypto maps, “denied” traffic is actually compared to subsequent (lower priority) crypto map ACLs
to see if there is a match. IPsec security associations (SAs) are not generated for deny rules.
Following is a summary of the security policies that you can configure, in priority order:
Group member security policy—When you configure the group member, as described in
Configuring GET VPN Group Members, page 28-20, you can optionally select an ACL policy object
that defines the local group member security policy.
This group member ACL policy object is allowed to have deny statements only. You use this ACL
to identify any traffic that you want to exclude from encryption and send in the clear. For example,
if a handful of group members in the group are running a different routing protocol than the usual
one, you can configure a local entry to these group members’ security policy ACL to bypass
encryption of the routing protocol traffic instead of defining the policy globally at the key server
level.