-
Cisco IOS Security Configuration Guide: Secure Connectivity, Release 12.4T
-
Overview: Secure Connectivity
-
Internet Key Exchange for IPsec VPNs
-
Configuring Internet Key Exchange for IPsec VPNs
-
Call Admission Control for IKE
-
Certificate to ISAKMP Profile Mapping
-
Encrypted Preshared Key
-
Fragmentation of IKE Packets
-
IKE Responder-Only Mode
-
Distinguished Name Based Crypto Maps
-
IPsec and Quality of Service
-
VRF-Aware IPsec
-
IKE: Initiate Aggressive Mode (12.2(8)T FM)
-
-
Security for VPNs with IPsec
-
Configuring Security for VPNs with IPsec
-
IPsec Virtual Tunnel Interface
-
L2TP—IPsec Support for NAT and PAT Windows Clients
-
SafeNet IPsec VPN Client Support
-
Ability to Disable Extended Authentication for Static IPsec Peers
-
Sharing IPsec with Tunnel Protection
-
Crypto Conditional Debug Support
-
VPN Acceleration Module (VAM)
-
Option to Disable Hardware Crypto Engine Failover to Software Crypto Engine
-
- VPN Availability
-
IPsec Data Plane
-
IPsec Anti-Replay Window: Expanding and Disabling
-
Pre-Fragmentation for IPsec VPNs
-
Invalid Security Parameter Index Recovery
-
IPsec Dead Peer Detection Periodic Message Option
-
IPsec NAT Transparency
-
DF Bit Override Functionality with IPsec Tunnels
-
Crypto Access Check on Clear-Text Packets
-
IPsec Security Association Idle Timers
-
Low Latency Queueing (LLQ) for IPsec Encryption Engines
-
- IPsec Management Plane
-
Public Key Infrastructure (PKI)
-
Implementing and Managing PKI Features Roadmap
-
Cisco IOS PKI Overview: Understanding and Planning a PKI
-
Deploying RSA Keys Within a PKI
-
Configuring Authorization and Revocation of Certificates in a PKI
-
Configuring Certificate Enrollment for a PKI
-
Setting Up Secure Device Provisioning (SDP) for Enrollment in a PKI
-
Configuring and Managing a Cisco IOS Certificate Server for PKI Deployment
-
Storing PKI Credentials
-
Source Interface Selection for Outgoing Traffic with Certificate Authority (CA)
-
- Dynamic Multipoint VPN (DMVPN)
- Easy VPN
-
Cisco Group Encrypted Transport VPN
- SSL VPN
-
Table Of Contents
Cisco Group Encrypted Transport VPN
Prerequisites for Cisco Group Encrypted Transport VPN
Restrictions for Cisco Group Encrypted Transport VPN
Information About Cisco Group Encrypted Transport VPN
Cisco Group Encrypted Transport VPN Overview
Cisco Group Encrypted Transport VPN Architecture
Key Distribution: Group Domain of Interpretation
Cisco Group Encrypted Transport VPN Features
Group Member Access Control List
Enhanced Solutions Manageability
Support with VRF-Lite Interfaces
How to Configure Cisco Group Encrypted Transport VPN
Setting Up RSA Keys to Sign Rekey Messages
Setting Up the Group ID, Server Type, and SA Type
Setting Up an IPsec Lifetime Timer
Setting Up an ISAKMP Lifetime Timer
Configuring Time-Based Anti-Replay for a GDOI Group
Changing the Role of the Key Server
Setting Up the Group Name, ID, Key Server IP Address and Group Member registration
Applying the Crypto Map to an Interface to Which the Traffic Has to Be Encrypted
Configuring ciphers or hash algorithms for KEK
Configuring Acceptable Transform Sets for TEK
Verifying and Troubleshooting Cisco Group Encrypted Transport VPN
Verifying Active Group Members on a Key Server
Verifying Rekey-Related Statistics
Verifying IPsec SAs That Were Created by GDOI on a Group Member
Verifying IPsec SAs That Were Created by GDOI on a Key Server
Verifying Cooperative Key Server States and Statistics
Verifying Anti-Replay Pseudotime-Related Statistics
Verifying the Fail-Close Mode Status of a Crypto Map
Configuration Examples for Cisco Group Encrypted Transport VPN
Key Server and Group Member Case Study
Feature Information for Cisco Group Encrypted Transport VPN
Cisco Group Encrypted Transport VPN
First Published: November 17, 2006
Last Updated: November 26, 2009
Note
Effective with Cisco IOS 12.4(11)T, the Multicast Rekeying feature information (originally published as Cisco IOS Release 12.4(6)T [titled Secure Multicast]) has been integrated into this document.
Today's networked applications, such as voice and video, are accelerating the need for instantaneous, branch-interconnected, and Quality of Service- (QoS-) enabled WANs. The distributed nature of these applications results in increased demands for scale. At the same time, enterprise WAN technologies force businesses to trade off between QoS-enabled branch interconnectivity and transport security. As network security risks increase and regulatory compliance becomes essential, Cisco Group Encrypted Transport VPN (GET VPN) eliminates the need to compromise between network intelligence and data privacy.
GET VPN eliminates the need for tunnels. By removing the need for point-to-point tunnels, meshed networks are able to scale higher while maintaining network-intelligence features that are critical to voice and video quality, such as QoS, routing, and multicast. GET VPN offers a new standards-based IP security (IPsec) security model that is based on the concept of "trusted" group members. Trusted member routers use a common security methodology that is independent of any point-to-point IPsec tunnel relationship.
GET VPN is a set of features that are necessary to secure IP multicast group traffic or unicast traffic over a private WAN that originates on or flows through a Cisco IOS device. GET VPN combines the keying protocol Group Domain of Interpretation (GDOI) with IPsec encryption to provide users with an efficient method to secure IP multicast traffic or unicast traffic. GET VPN enables the router to apply encryption to nontunneled (that is, "native") IP multicast and unicast packets and eliminates the requirement to configure tunnels to protect multicast and unicast traffic.
Cisco Group Encrypted Transport VPN provides the following benefits:
•
•
•
•
•
•
Finding Feature Information
Your software release may not support all the features documented in this module. For the latest feature information and caveats, see the release notes for your platform and software release. To find information about the features documented in this module, and to see a list of the releases in which each feature is supported, see the "Feature Information for Cisco Group Encrypted Transport VPN" section.
Use Cisco Feature Navigator to find information about platform support and Cisco IOS and Catalyst OS software image support. To access Cisco Feature Navigator, go to http://www.cisco.com/go/cfn. An account on Cisco.com is not required.
Contents
•
•
•
•
•
•
Prerequisites for Cisco Group Encrypted Transport VPN
•
–
–
–
•
•
•
Restrictions for Cisco Group Encrypted Transport VPN
•
•
•
•
•
•
Note
•
Note
•
•
•
%GDOI-3-GDOI_REKEY_SEQ_FAILURE: Failed to process rekey seq # 2 in seq payload for group get-group, last seq # 6or
%GDOI-3-PSEUDO_TIME_TOO_OLD: Rekey received in group get-group is too old and failed PST check: my_pst is 184 sec, peer_pst is 25 sec, allowable_skew is 10 secInformation About Cisco Group Encrypted Transport VPN
To configure GET VPN, you should understand the following concepts:
•
•
•
Cisco Group Encrypted Transport VPN Overview
Today's networked applications, such as voice and video, are accelerating the necessity for instantaneous, branch-interconnected, and QoS-enabled WANs. And the distributed nature of these applications results in increased demands for scale. At the same time, enterprise WAN technologies force businesses to trade off between QoS-enabled branch interconnectivity and transport security. As network security risks increase and regulatory compliance becomes essential, GET VPN, a next-generation WAN encryption technology, eliminates the need to compromise between network intelligence and data privacy.
With the introduction of GET, Cisco now delivers a new category—tunnel-less VPN—that eliminates the need for tunnels. By removing the need for point-to-point tunnels, meshed networks can scale higher while maintaining network-intelligence features critical to voice and video quality. GET offers a new standards-based security model that is based on the concept of "trusted" group members. Trusted member routers use a common security methodology that is independent of any point-to-point IPsec tunnel relationship. By using trusted groups instead of point-to-point tunnels, "any-any" networks can scale higher while maintaining network-intelligence features (such as QoS, routing, and multicast), which are critical to voice and video quality.
GET-based networks can be used in a variety of WAN environments, including IP and Multiprotocol Label Switching (MPLS). MPLS VPNs that use this encryption technology are highly scalable, manageable, and cost-effective, and they meet government-mandated encryption requirements. The flexible nature of GET allows security-conscious enterprises either to manage their own network security over a service provider WAN service or to offload encryption services to their providers. GET simplifies securing large Layer 2 or MPLS networks that require partial or full-mesh connectivity.
Cisco Group Encrypted Transport VPN Architecture
GET VPN is an enhanced solution that encompasses Multicast Rekeying, a Cisco solution for enabling encryption for "native" multicast packets, and unicast rekeying over a private WAN. Multicast Rekeying and GET VPN is based on GDOI as defined in Internet Engineering Task Force (IETF) RFC 3547. In addition, there are similarities to IPsec in the area of header preservation and SA lookup. Dynamic distribution of IPsec SAs has been added, and tunnel overlay properties of IPsec have been removed. Figure 1 further illustrates the concepts of GET VPN and their relationships among one another.
Figure 1 GET VPN Concepts and Relationships
This section includes the following subsections:
•
Key Distribution: Group Domain of Interpretation
GDOI
GDOI is defined as the Internet Security Association Key Management Protocol (ISAKMP) Domain of Interpretation (DOI) for group key management. In a group management model, the GDOI protocol operates between a group member and a group controller or key server (GCKS), which establishes security associations (SAs) among authorized group members. The ISAKMP defines two phases of negotiation. GDOI is protected by a Phase 1 ISAKMP security association. The Phase 2 exchange is defined in IETF RFC 3547. The topology shown in Figure 2 and the corresponding explanation show how this protocol works.
Group Member
The group member registers with the key server to get the IPsec SA or SAs that are necessary to communicate with the group. The group member provides the group ID to the key server to get the respective policy and keys for this group. These keys are refreshed periodically, and before the current IPsec SAs expire, so that there is no loss of traffic.
Key Server
The responsibilities of the key server include maintaining the policy and creating and maintaining the keys for the group. When a group member registers, the key server downloads this policy and the keys to the group member. The key server also rekeys the group before existing keys expire.
Note
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 this ID is a valid group ID, the key server sends the SA policy to the group member. After the group member acknowledges that it can handle the downloaded policy, the key server downloads the respective keys.
There are two types of keys that the key server can download: the key encryption key (KEK) and the traffic encryption key (TEK). The TEK becomes the IPsec SA with which the group members within the same group communicate. The KEK encrypts the rekey message.
The GDOI server sends out rekey messages if an impending IPsec SA expiration occurs or if the policy has changed on the key server (using command-line interface [CLI]). A rekey can also happen if the KEK timer has expired, and the key server sends out a KEK rekey. The rekey messages may also be retransmitted periodically to account for possible packet loss. Packet loss can occur because rekey messages are sent without the use of any reliable transport. 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 will send an acknowledgement message.
Figure 2 Protocol Flows That Are Necessary for Group Members
to Participate in a Group
The above topology shows the protocol flows that are necessary for group members to participate in a group, which are as follows:
1.
2.
How Protocol Messages Work with the Cisco IOS
Multicast Rekeying uses the GDOI protocol (IETF RFC 3547) to distribute the policy and keys for the group. The GDOI protocol is between a key server and a group member. The key server creates and maintains the policy and keys, and it downloads the policy and keys to the authenticated group members. The group members are authenticated by the key server and communicate with other authenticated group members that are in the same group using the IPsec SAs that the group members have received from the key server.
The GDOI protocol is protected by an ISAKMP Phase 1 exchange. The GDOI key server and the GDOI group member must have the same ISAKMP policy. This Phase 1 ISAKMP policy should be strong enough to protect the GDOI protocol that follows. The GDOI protocol is a four-message exchange that follows the Phase 1 ISAKMP policy. The Phase 1 ISAKMP exchange can occur in main mode or aggressive mode.
Figure 3 shows the ISAKMP Phase 1 exchange.
Figure 3 ISAKMP Phase 1 Exchange and GDOI Registration
The above messages (the ISAKMP Phase 1 messages and the four GDOI protocol messages) are referred to as the GDOI registration, and the entire exchange that is shown above is a unicast exchange between the group member and the key server.
During the registration, if the rekey mechanism is multicast, the group member receives the address of the multicast group and registers with the multicast group that is required to receive the multicast rekeys.
Note
IPsec
IPsec is a well-known RFC that defines an architecture to provide various security services for traffic at the IP layer. The components and how they fit together with each other and into the IP environment are described in IETF RFC 2401.
Communication Flow Between Key Servers and Group Members to Update IPsec SAs
Key servers and group members are the two components of the GET VPN architecture. The key server holds and supplies group authentication keys and IPsec SAs to the group members.
Group members provide encryption service to the interesting traffic (traffic that is worthy of being encrypted and secured by IPsec).
Communication among the key server and group members is encrypted and secured. GDOI supports the use of two keys: The TEK and the 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 generates the group policy and IPsec SAs for the GDOI group. The information generated by the key server includes multiple TEK attributes, traffic encryption policy, lifetime, source and destination, a Security Parameter Index (SPI) ID that is associated with each TEK, and the rekey policy (one KEK).
Figure 4 illustrates the communication flow between group members and the key server. The key server, after receiving registration messages from a group member, generates the information that contains the group policy and new IPsec SAs. The new IPsec SA is then downloaded to the group member. The key server maintains a table that contains the IP address of each group member per group. When a group member registers, the key server adds its IP address in its associated group table, thus allowing the key server to monitor an active group member. A key server can support multiple groups. A group member can be part of multiple groups.
Figure 4 Communication Flow Between Group Members and the Key Server
IPsec and ISAKMP Timers
IPsec and ISAKMP SAs are maintained by the following timers:
•
•
•
Routing
GET VPN routing is explained in the following section.
Header Preservation
As shown in Figure 5, IPsec-protected data packets carry the original source and destination in the outer IP header rather than replacing them with tunnel endpoint addresses. This technique is known as IPsec Tunnel Mode with Address Preservation.
Figure 5 Header Preservation
Address preservation allows GET VPN to use the routing functionality present within the core network. Address preservation allows routing to deliver the packets to any customer-edge device (CE) in the network that advertises a route to the destination address. Any source and destination matching the policy for the group will be treated in a similar manner. In the situation where a link between IPsec peers is not available, address preservation also helps combat traffic "black-hole" situations.
Header preservation also maintains routing continuity throughout the enterprise address space and in the WAN. As a result, end host addresses of the campus are exposed in the WAN (for MPLS, this applies to the edge of the WAN). For this reason, GET VPN is applicable only when the WAN network acts as a "private" network (for example, in an MPLS network).
Secure Data Plane Multicast
The multicast sender uses the TEK that is obtained from the key server and encrypts the multicast data packet with header preservation before it switches out the packet. The replication of the multicast packet is carried out in the core on the basis of the (S,G) state that is retained in the multicast data packet. This process is illustrated in Figure 6.
Figure 6 Secure Data Plane Multicast Process
Secure Data Plane Unicast
The unicast sender uses the TEK that is obtained from the key server and encrypts the unicast data packet with header preservation before it switches out the packet to the destination. This process is illustrated in Figure 7.
Figure 7 Secure Data Plane Unicast Process
Cisco Group Encrypted Transport VPN Features
This section includes the following subsections:
•
•
•
Rekeying
Rekey messages are used to refresh IPsec SAs. When the IPsec SAs or the rekey SAs are about to expire, one single rekey message for a particular group is generated on the key server. No new IKE sessions are created for the rekey message distribution. The rekey messages are distributed by the key server over an existing IKE SA.
Rekeying can use multicast or unicast messages. GET VPN supports both unicast and multicast rekeying.
Multicast Rekeying
Multicast rekeys are sent out using an efficient multicast rekey. Following a successful registration, the group member registers with a particular multicast group. All the group members that are registered to the group receives this multicast rekey. Multicast rekeys are sent out periodically on the basis of the configured lifetime on the key server. Multicast rekeys are also sent out if the IPsec or rekey policy is changed on the key server. Triggered by the configuration change, the rekey sends out the new updated policy to all the group members with an efficient multicast rekey.
The key server pushes the rekey time back as follows:
1. If the TEK timeout is 300 seconds:
tek_rekey_offset = 90 (because 300 < 900)
If retransmissions are configured, the rekey timer is moved back more.
For three retransmissions every 10 seconds: 3 * 10
So the rekey will actually happen at (300 - 90 - 30) = 180 seconds
2. If the TEK timeout is 3600 seconds:
tek_rekey_offset = 3600 * 0% = 360 seconds
If retransmissions are configured, the rekey timer is moved back more.
For three retransmissions every 10 seconds: 3 * 10
So the rekey will actually happen at (3600 - 360 - 30) = 3210 seconds
When a key encryption key (KEK) expires and when the transport mode is multicast, a multicast KEK rekey is sent. When a multicast KEK rekey is sent, the group member replaces the old KEK with the new KEK. Because it is a multicast rekey, and the retransmissions are sent, the old KEK continues to be used for encryption. This situation occurs because the group member does not receive the new KEK rekey. Hence the group member that received the multicast KEK rekey does not have the old KEK, and hence it drops these retransmissions.
The group member that did not initially receive the KEK key, now receives the KEK retransmission and replaces the old KEK with the new KEK and will drop the retransmissions that will follow. For example, if 5 retransmissions are configured and a multicast KEK rekey with sequence number 1 is received at group member 1, all the other retransmissions with sequence numbers 2 3 4 5 6 will be dropped at the group member because the group member does not have the old KEK.
If group member 2 does not get the KEK rekey with sequence number 1 and it receives the retransmission with sequence number 2, it will drop the other retransmissions 3,4,5,6.
Unicast Rekeying and SAs
In a large unicast group, to alleviate latency issues, the key server generates rekey messages for only a small number of group members at a time. The key server is ensured that all group members receive the same rekey messages for the new SA before the expiration of the old SA. Also, in a unicast group, after receiving the rekey message from the key server, a group member sends an encrypted acknowledge (ACK) message to the key server using the keys that were received as part of the rekey message. When the key server receives this ACK message, it notes this receipt in its associated group table, which accomplishes the following:
•
•
In addition, in a unicast group, the key server removes the group member from its active list and stops sending the rekey messages to that particular group member if the key server does not receive an ACK message for three consecutive rekeys. If no ACK message is received for three consecutive rekeys, the group member has to fully reregister with the key server after its current SA expires if the group member is still interested in receiving the rekey messages. The ejection of a nonresponsive group member is accomplished only when the key server is operating in the unicast rekey mode. The key server does not eject group members in the multicast rekey mode because group members cannot send ACK messages in that mode.
As in multicast rekeying, if retransmission is configured, each rekey will be retransmitted the configured number of times.
Rekey transport modes and authentication can be configured under a GDOI group.
If unicast rekey transport mode is not defined, multicast is applied by default.
If the TEK rekey is not received, the group member reregisters with the key server 60 seconds before the current IPsec SA expires. The key server has to send out the rekey before the group member reregistration occurs. If no retransmission is configured, the key server sends the rekey tek_rekey_offset before the SA expires. The tek_rekey_offset is calculated based on the configured rekey lifetime. If the TEK rekey lifetime is less than 900 seconds, the tek_rekey_offset is set to 90 seconds. If the TEK rekey lifetime is configured as more than 900 seconds, the tek_rekey_offset = (configured TEK rekey lifetime)/10. If retransmission is configured, the rekey occurs earlier than the tek_rekey_offset to let the last retransmission be sent 90 seconds before the SA expires.
The key server uses the formula in the example below to calculate when to start sending the rekey to all unicast group members. The unicast rekey process on the key server sends rekeys to unicast group members in groups of 50 within a loop. The time spent within this loop is estimated to be 5 seconds.
A key server rekeys group members in groups of 50, which equals two loops. For example, for 100 group members:
Number of rekey loops = (100 group members)/50 = 2 loops
Time it takes to rekey one loop (estimation) = 5 seconds
Time to rekey 100 group members in two loops of 50: 2 * 5 seconds = 10 seconds
So the key server pushes the rekey time back as follows:
If the TEK timeout is 300: 300 - 10 = 290
But the start has to be earlier than the TEK expiry (as in the multicast case).
Because 300 < 900, tek_rekey_offset = 90
So 90 seconds is subtracted from the actual TEK time: 290 - tek_rekey_offset = 200 seconds
If retransmissions are configured, the rekey timer is moved back more.
For three retransmissions every 10 seconds: 200 - (3 * 10) = 170
If the TEK timeout is 3600 seconds: 3600 - 10 = 3590
But the start has to be earlier than the TEK expiry (as in the multicast case).
Because 3600 > 900, tek_rekey_offset = 3600 * 10% = 360
So 360 seconds is subtracted from the actual TEK time: 3590 - tek_rekey_offset = 3230 seconds.
If retransmissions are configured, the rekey timer is moved back more.
For three retransmissions every 10 seconds: 3230 - (3 * 10) = 3200 seconds
Note
Rekey Behavior After Policy Changes
Table 1 provides a list of rekey behavior based on the security policy changes.
Perform the following steps for the policy changes to take effect immediately.
•
•
IPsec SA Usage on the Group Members
When a rekey is received and processed on a group member, the new IPsec SA (the Security Parameter Index [SPI]) is installed. There is a period of time when the old and the new IPsec SAs are used. After a certain specified interval, the old IPsec SA is deleted. This overlap ensures that all group members receive the current rekey and insert the new IPsec SAs. This behavior is independent of the transport method (multicast or unicast rekey transport) for the rekeys from the key server.
On the group member, approximately 30 seconds before the old SA expires, the group member starts to use the new SA in the outbound direction to encrypt the packet. Approximately 60 seconds before the old SA expires, if no new SA is received on the group member side via a rekey from the key server, the group member reregisters.
Figure 8 IPsec SA Usage on a Group Member
In Figure 8, time T2 is when the old SA expires. T1 is 30 seconds before T2, which is when the group member (GM) starts to use the new SA in the outbound direction. T0 is another 30 seconds before T2. If no new SA is received at T0, the group member has to reregister. T is another 30 seconds from T0. The key server should send a rekey at T.
Configuration Changes Can Trigger a Rekey By a Key Server
Configuration changes on a key server can trigger a rekey by the key server. Please refer to the following sample configuration as you read through the events that will or will not cause a rekey.
crypto ipsec transform-set gdoi-p esp-3des esp-sha-hmac!crypto ipsec profile gdoi-pset security-association lifetime seconds 900set transform-set gdoi-p!crypto gdoi group diffintidentity number 3333server localrekey algorithm aes 128rekey address ipv4 121rekey lifetime seconds 3600no rekey retransmitrekey authentication mypubkey rsa mykeyssa ipsec 1profile gdoi-pmatch address ipv4 120replay counter window-size 3Changes That Will Trigger a Rekey on a Key Server
•
–
–
–
–
–
Changes That Will Not Trigger a Rekey on a Key Server
The following configuration changes on the key server will not trigger a rekey from the key server:
•
•
•
•
•
Commands That Trigger a Rekey
Table 2 is a comprehensive list of GET VPN command changes, and it shows which commands will trigger a rekey and which commands will not. Commands are broken out based on the configuration mode in which they are entered. The table also shows when the commands take effect, regardless of whether they trigger a rekey.
Group Member Access Control List
For GET VPN, the traffic that has to be protected is defined statically on the key server using the access control list (ACL). The group member gets information about what has to be protected from the key server. This structure allows the key server to choose and change the policy dynamically as needed. In Secure Multicast, the key server ACL is defined inclusively. The ACL includes only the exact traffic that should be encrypted, with an implicit deny causing all other traffic to be allowed in the clear (that is, if there is no permit, all other traffic is allowed).
GET VPN employs a different philosophy: the definition of which packets should be encrypted is delivered independently. GET VPN supports only statically defined traffic selectors. Policy can be defined by using both deny and permit ACLs on the key server. Only the deny ACL is allowed to be manually configured on a group member. The policies that are downloaded from the key server and configured on the group member are merged. Any ACL that is configured on the group member has predominance over what is downloaded from the key server.
After the group member gets the ACL from the key server, the group member creates a temporary ACL and inserts it into the database. This ACL will be deleted if the group member is removed from the GDOI group for any reason. The packets that are going out of the interface are dropped by the group member if a packet matches the ACL but no IPsec SA exists for that packet.
The key server can send a set of traffic selectors, which may not exactly match the group member ACL on the group member. If such differences occur, the differences have to be merged and resolved. Because the group member is more aware of its topology than the key server, the downloaded ACLs are appended at the end of the group member ACL. The group member ACL (except the implicit deny) is inserted into the database first, followed by the downloaded key server ACL. The database is prioritized, and the database search stops whenever a matched entry is found.
For information about configuring a group member ACL, see "Setting Up Group Member ACLs" section."
Behavior of a Group Member When Security Policy Changes
The behavior of a group member changes when ACL changes or any other policy changes are made in the key server. The effect of different policy changes on the behavior of the group members is explained in three different scenarios below:
Scenario I
In the following example, the ACL has been initially configured to permit host A and host B.
ip access-list extended get-aclpermit ip host A host Bpermit ip host B host AThen the ACL is changed to permit host C and host D in the key server:
ip access-list extended get-aclpermit ip host C host Dpermit ip host D host CACL changes affect the behavior of the group member in the following ways:
•
•
•
Scenario II
The behavior of a group member changes when policy updates transform set and TBAR changes are made to the key server.
In this scenario, it is assumed that:
•
•
These policy changes affect the behavior of the group member in the following ways:
•
•
•
Scenario III
The behavior of a group member changes when there are other policy updates in the key server that involve both ACL changes and other changes like transform set or TBAR.
In this scenario it has been assumed that:
•
•
•
ACL changes and other policy updates affect the behavior of the group member in the following ways:
•
•
•
•
Fail-Close Mode
Overview
Before a group member registers with a key server, traffic passing through the group member is not encrypted. This state is called "fail open." To prevent unencrypted traffic from passing through a group member before that member is registered, you can configure the Fail-Close feature. If the feature is configured, an implicit "permit ip any any" policy is installed, and all unencrypted traffic passing through the group member is dropped (this state is called fail-close mode).
Note
If you configure the Fail-Close feature, you can still allow specific unencrypted traffic to pass through the group member by configuring the match address command (match address {access-list-number | access-list-name}). This explicit "deny" ACL is added before the implicit "permit ip any any" to allow denied (unencrypted) traffic to pass through the group member.
After the group member has successfully completed its registration, the fail-close policy, both explicit and implicit, is removed, and the group member behaves as it did before the Fail-Close feature was configured.
Guidelines for Using the Fail-Close Feature
When you are configuring a crypto map to work in fail-close mode, you must be careful. If the fail-close ACL is defined improperly, you may lock yourself out of the router. For example, if you use Secure Shell (SSH) to log in to the router through the interface with the crypto map applied, you have to include the deny tcp any eq port your host address command line under the fail-close ACL. You may also need to include the routing protocol that the router is using (such as deny ospf any any) to find the path to the key server. It is suggested that you configure fail-close and its ACL first, and then verify the fail-close ACL using the show crypto map command (show crypto map gdoi fail-close map-name). After you have checked your fail-close ACL and are confident that it is correct, you can make the crypto map work in the fail-close mode by configuring the activate command. Fail-close is not activated until you have configured the activate command.
The fail-close ACL is configured from the group-member perspective. The fail-close ACL is configured on group member as follows:
access-list 125 deny ip host host1-ip-addr host2-ip-addr
In fail-close mode, all IP traffic from host1 to host2 will be sent out by group member 1 in clear text. In addition, the inbound mirrored traffic (that is, IP traffic from host2 to host1) is also accepted by GM1 in clear text.
Note
Note
Note
To make the GDOI registration go through, you do not have to configure an explicit deny udp any eq 848 any eq 848 command line. The code itself will check to determine whether it is a GDOI packet for a particular group member from the key server to which it is configured. If it is a GDOI packet for this group member, the packet is processed. But for a scenario in which the key server is behind group member 1, if group member 1 cannot register successfully with the key server, other group members also will not be able to register unless an explicit deny udp any eq 848 any eq 848 command line is configured for group member 1. However, if the Fail-Close feature is properly configured, even if a group member fails to register with a key server, you will be able to ensure that no unwanted traffic can go out "in the clear." But you can allow specified traffic to go out in the clear, in which case, registration packets from other group members will be able to reach the key server through group member 1 even it fails to get registered.
To configure fail-close mode, see the "Configuring Fail-Close Mode" section.
To verify whether fail-close mode is activated, use the show crypto map gdoi fail-close command.
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.
GET VPN uses the Synchronous Anti-Replay (SAR) mechanism to provide anti-replay protection for multisender traffic. SAR is independent of real-world Network Time Protocol (NTP) clock or sequential-counter mechanisms (which guarantee packets are received and processed in order). A SAR clock advances regularly. The time tracked by this clock is called pseudotime. The pseudotime is maintained on the key server and is sent periodically to the group members within a rekey message as a timestamp field called pseudoTimeStamp. GET VPN uses a Cisco proprietary protocol called Metadata to encapsulate the pseudoTimeStamp. Group members have to be resynchronized to the pseudotime of the key server periodically. The pseudotime of the key server starts ticking from when the first group member registers. Initially, the key server sends the current pseudotime value of the key server and window size to group members during the registration process. New attributes, such as time-based replay-enabled information, window size, and the pseudotime of the key server, is sent under the SA payload (TEK).
The group members use the pseudotime to prevent replay as follows: the pseudoTimeStamp contains the pseudotime value at which a sender created a packet. A receiver compares the pseudotime value of senders with its own pseudotime value to determine whether a packet is a replayed packet. The receiver uses a time-based anti-replay "window" to accept packets that contain a timestamp value within that window. The window size is configured on the key server and is sent to all group members.
Note
Figure 9 illustrates an anti-replay window in which the value PTr denotes the local pseudotime of the receiver, and W is the window size.
Figure 9 Anti-Replay Window
Keeping Clocks Synchronized
It is possible for the clocks of the group members to slip and lose synchronization with the key server. To keep the clocks synchronized, a rekey message (multicast or unicast, as appropriate), including the current pseudotime value of the key server, is sent periodically (either in a rekey message or at a minimum of every 30 minutes to the group member. If a packet fails this anti-replay check, the pseudotime of both the sender and receiver is printed, an error message is generated, and a count is increased.
To view anti-replay statistics, use the show crypto gdoi group group-name gm replay command on both the sender and receiver devices. If the configuration is changed by the administrator to affect the replay method of the size configuration, the key server initiates a rekey message.
Interval Duration
A tick is the interval duration of the SAR clock. Packets sent in this duration have the same pseudoTimeStamp. The tick is also downloaded to group members, along with the pseudotime from the key server. For example, as shown in Figure 10, packets sent between T0 and T1 would have the same pseudoTimeStamp T0. SAR provides loose anti-replay protection. The replayed packets are accepted if they are replayed during the window. The default window size is 100 seconds. It is recommended that you keep the window size small to minimize packet replay.
Figure 10 SAR Clock Interval Duration
Anti-Replay Configurations
The Anti-Replay feature can be enabled under IPsec SA on a key server by using the following commands:
•
•
•
Cooperative Key Server
Figure 11 illustrates cooperative key server key distribution. The text below the illustration explains the Cooperative Key Server feature.
Figure 11 Cooperative Key Server Key Distribution
Cooperative key servers provide redundancy to GET VPN. Multiple key servers are supported by GET VPN to ensure redundancy, high availability, and fast recovery if the primary key server fails. Cooperating GDOI key servers jointly manage the GDOI registrations for the group. Each key server is an active key server, handling GDOI registration requests from group members. Because the key servers are cooperating, each key server distributes the same state to the group members that register with it. Load balancing is achieved because each of the GDOI key servers can service a portion of the GDOI registrations.
The primary key server is responsible for creating and distributing group policy. The primary key server periodically sends out (or broadcasts) group information updates to all other key servers to keep those servers in synchronization. If the secondary key servers somehow miss the updates, they contact the primary key server to directly request information updates. The secondary key servers mark the primary key server as unreachable (that is, "dead") if the updates are not received for an extended period of time.
When a new policy is created on a primary key server, regardless of which key server a group member may be registered with, it is the responsibility of the primary key server to distribute rekey messages to GDOI group members.
Note
Announcement Messages
Announcement messages are secured by IKE Phase 1 and are sent as IKE notify messages. Authentication and confidentiality that are provided by IKE is used to secure the messaging between the key servers. Anti-replay protection is provided by the sequence numbers in the announcement messages. Announcement messages are periodically sent from primary to secondary key servers.
Announcement messages include the following components that help maintain the current state.
Sender Priority of a Key Server
This value describes the priority of the sender, which is configurable using the CLI. The key server with the highest priority becomes the primary key server. If the priority values are the same, the key server with the highest IP address becomes the primary key server.
Maintaining the Role of the Sender
During the synchronization period, if the key servers are at geographically dispersed locations, they may suffer a network-partitioning event. If a network-partitioning event occurs, it is possible that more than one key server can become the primary key server for a period of time. When the network is operating normally again and all the key servers find each other, they need to be told the current role of the sender so the key servers can attain their proper roles.
Request for a Return Packet Flag
All messages are defined as one-way messages. When needed, a key server can request the current state from a peer to find out its role and/or request the current state of the group.
Group Policies
The group policies are the policies that are maintained for a group, such as group member information and IPsec SAs and keys.
Anti-replay functionalities and incorporated Cooperative announcement messages are supported. The primary key server updates the pseudotime value, sending it to all secondary key servers in the group. The secondary key servers should synchronize their SAR clocks to this updated value.
Change Key Server Role
In a network of cooperative key servers, the primary server is elected based on its highest priority at the time of election. The other key servers have secondary status. If the primary key server is detected as being dead or if its role changes, the clear crypto gdoi ks cooperative role command allows you to reset the cooperative role of the primary key server.
If the clear crypto gdoi ks cooperative role command is executed on a secondary key server, the election is triggered on that secondary key server although that server would most likely remain a secondary key server because there has been an elected primary key server. However, if the clear crypto gdoi ks cooperative role command is executed on the primary key server, the primary key server is reassigned to a secondary role, and as a result, a new election that involves all the key servers is triggered. If the previous primary server has the highest priority (of all the key servers), it again becomes the primary server. If the previous primary server does not have the highest priority, the server having the highest priority is elected as the new primary server.
Receive Only SA
For multicast traffic using the GDOI protocol, bidirectional SAs are installed. The Receive Only feature enables an incremental deployment so that only a few sites can be verified before bringing up an entire network. To test the sites, one of the group members should send encrypted traffic to all the other group members and have them decrypt the traffic and forward the traffic "in the clear." Receive Only SA mode allows encryption in only the inbound direction for a period of time. (See the steps below for the Receive Only SA process.) If you configure the sa receive-only command on the key server, Steps 2 and 3 happen automatically.
1.
This action allows the group members to install SAs in the inbound direction only. Receive-only SAs can be configured under a crypto group. (See "Setting Up the Group ID, Server Type, and SA Type" section.")
2.
If the sa receive-only command is configured, all TEKs under this group are going to be marked "receive only" by the key server when they are sent to the group member.
3.
Every time a GDOI group member receives an IPsec SA from the key server that is marked as "receive only," the group member installs this IPsec SA only in the inbound direction rather than in both incoming and outgoing directions.
4.
•
•
Local Conversion
First, individually convert each of the group members to passive mode (this change tells the outbound check that there is a valid SA ) and then to bidirectional mode.
5.
The following method can be used when the testing phase is over and "receive only" SAs have to be converted to bidirectional SAs.
Global Conversion
Remove the sa receive-only command under the group. Removing the sa receive-only command creates new IPsec SAs for this group and causes a rekey. On receipt, group members reinstall the SA in both directions and begin to use it in passive mode. Because the SA cannot remain in passive mode forever, the group members change those SAs to receive or send mode if there is no rekey in 5 minutes. The conversion from passive mode to bidirectional encryption mode is automatic and does not require the administrator to do anything.
Passive SA
The Passive SA feature allows you to configure a group member so that it is in passive mode permanently. By using the Passive SA feature, you will avoid having to use the crypto gdoi gm ipsec direction inbound optional privileged EXEC command, which is not persistent after a router reload and can be overridden by key server configuration from a rekey. Having the group member in passive mode benefits network testing and debugging during migration to GET VPN, and it provides complete encryption protection during the migration. The group-member passive-mode configuration has higher priority over a key server configuration. The crypto gdoi gm ipsec direction inbound optional privileged EXEC command can override the configuration until the next rekey, which will bring back the group member and key server configuration.
To configure the Passive SA feature, see "Configuring Passive SA" section.
Enhanced Solutions Manageability
Several show and debug commands are supported to help verify functionality. See the "Configuring Fail-Close Mode" section for the details.
Support with VRF-Lite Interfaces
Note
VRF-Lite application supports segmentation of traffic in the control and forwarding planes by keeping the routing tables separate for each user group (or VPN) and forwards the traffic on the associated or dedicated interfaces of each user group.
There are some deployment scenarios in which remote sites that are connecting to an MPLS VPN network might be extending segmentation from a campus to the WAN. In such an extended segmentation case, a CE-PE interface on a CE (group member or key server) device "bounds" to its associated Virtual Routing Forwarding (VRF) instance. This VRF interface connects to an MPLS PE device where it is directly mapped to its associated Border Gateway Protocol (BGP) VRF process, in which case the crypto map is applied to a VRF interface. No other configuration changes are necessary.
GET VPN VRF-Aware GDOI on GM
The GET VPN VRF-Aware GDOI on GM feature adds to the GET VPN feature. The GET VPN VRF-Aware GDOI on GM feature allows control plane traffic (for example, GDOI registration) to be placed in a separate VRF (for example, a dedicated management VRF). Multiple entities placed in different MPLS VPNs (VRFs) can share the same key servers.
Use the client registration interface command to allow GDOI crypto maps to route registrations and receive rekeys through a different VRF.
The following scenarios are supported.
Shared GDOI Groups/Policies and Crypto Maps:
The same crypto map is applied to multiple subinterfaces, and each subinterface is in a different VRF context or same VRF context, and the key server is accessible through a different VRF or global VRF table. This is addressed by separating out the control traffic.
There is one group member registration for all the crypto maps applied to different subinterfaces. After successful registration, policies are downloaded to where the crypto maps are.
Different Groups/Policies with Different Crypto Maps Sharing a Key Server
Different groups applied to different interfaces, each of these interfaces is in a different VRF context or same VRF context. All these groups are accessing the same key server, and this key server is accessible through a different VRF or global VRF table. This is addressed by having individual group members registering for each group.
So for every group, there is one registration and also one unicast rekey received. All these group members would be using the same IKE SA which is established between the CE and the key server.
Different Groups/Policies with Different Crypto Maps on Different Key Servers
Different groups applied to different interfaces, and each of these interface is in a different VRF context or same VRF context. All these groups are accessing different key servers, and these key servers are accessible through a different VRF or the global VRF table. This is addressed by having a group member registering for each group. So for every group, there is one registration and also one unicase rekey received. Because every registration is with a different key server, there is a different IKE SA established for every registration.
End-User Considerations
Multicast rekeying can be used with all modes of multicast. The rekey retransmit command should be used whenever the Protocol Independent Multicast-sparse mode (PIM-SM) is configured because the PIM-SM shortest path tree (SPT) can be torn down if it does not receive continuing traffic. When traffic resumes, PIM-SM must reestablish the SPT. Retransmitting rekey packets increases the chance that group members receive the rekeys when PIM-SM is setting up the SPT.
System Error Messages
For a list of system error messages, see Appendix I: System Messages.
How to Configure Cisco Group Encrypted Transport VPN
This section includes the following required and optional tasks:
•
•
Setting Up a Key Server
To set up a key server, perform the steps in the following subtasks.
•
•
•
•
•
•
•
•
•
•
Prerequisites
Before creating the GDOI group, you must first configure IKE and the IPsec transform set, and you must create an IPsec profile. For information about how to configure IKE and the IPsec transform set and to create an IPsec profile, see the "Related Documents" subsection of the "Additional References" section.
Setting Up RSA Keys to Sign Rekey Messages
To set up RSA keys that will be used to sign rekey messages, perform the following steps.
Note
SUMMARY STEPS
1.
2.
3.
DETAILED STEPS
What to Do Next
Set up the group ID, server type, and SA type. (See the section "Setting Up the Group ID, Server Type, and SA Type" section.)
Setting Up the Group ID, Server Type, and SA Type
To set up the group ID, server type, and SA type, perform the following steps.
Note
SUMMARY STEPS
1.
2.
3.
4.
or
identity address ipv4 address
5.
6.
DETAILED STEPS
What to Do Next
Remove the receive-only configuration on the key server so that the group members are now operating in bidirectional receive and send mode.
Setting Up the Rekey
Rekey is used in the control plane by the key server to periodically refresh the policy and IPsec SAs of the group. On the group-member side, instead of fully reregistering when timers expire for any other reasons, refreshing the registration with a rekey is more efficient. The initial registration is always a unicast registration.
The key server can be configured to send rekeys in unicast or multicast mode. The rekey transport mode is determined by whether the key server can use IP multicast to distribute the rekeys. If multicast capability is not present within the network of the customer, the key server will have to be configured to send rekeys using unicast messages.
Additional options for rekey use the rekey authentication, rekey retransmit, and rekey address ipv4 commands. If unicast transport mode is configured, the source address command will have to be included to specify the source address of this unicast rekey message.
Multicast is the default transport type for rekey messages. The following bulleted items explain when to use rekey transport type multicast or unicast:
•
Note
•
•
Note
The reregistering forces the default transport type to multicast. If no transport type was configured previously, the multicast transport type will apply by default.
Prerequisites
Before configuring the rekey authentication command, you must have configured the router to have a RSA key generated using the crypto key generate rsa command and general-keys and label keywords (for example, "crypto key generate rsa general-key label my keys").
Setting Up a Unicast Rekey
To set up a unicast rekey, perform the following steps.
Note
SUMMARY STEPS
1.
2.
3.
4.
or
identity address ipv4 address
5.
6.
7.
8.
9.
10.
DETAILED STEPS
Setting Up a Multicast Rekey
To set up a multicast rekey, perform the following steps.
SUMMARY STEPS
1.
2.
3.
4.
or
identity address ipv4 address
5.
6.
7.
8.
9.
10.
11.
12.
DETAILED STEPS
Setting Up Group Member ACLs
To set up group member ACLs, follow the summary steps considering the restriction provided below.
Restrictions
A group member access-list can only contain deny statements.
Note
Note
SUMMARY STEPS
1.
2.
3.
4.
DETAILED STEPS
What to Do Next
The above access list is the same one that should be used to set up the SA. See the "Setting Up the IPsec SA" section.
Setting Up an IPsec Lifetime Timer
To set up an IPsec lifetime timer for a profile, perform the following steps. If this configuration task is not performed, the default is the maximum IPsec SA lifetime of 3600 seconds.
Note
SUMMARY STEPS
1.
2.
3.
4.
DETAILED STEPS
What to Do Next
Configure the IPsec SA. See the "Setting Up the IPsec SA" section.
Setting Up an ISAKMP Lifetime Timer
To set up an ISAKMP lifetime timer, perform the following steps.
SUMMARY STEPS
1.
2.
3.
4.
DETAILED STEPS
Setting Up the IPsec SA
To set up the IPsec SA, perform the following steps.
Note
SUMMARY STEPS
1.
2.
3.
4.
or
identity address ipv4 address
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
DETAILED STEPS
What to Do Next
Replay should be configured. If not configured, the default is counter mode.
Configuring Time-Based Anti-Replay for a GDOI Group
To configure time-based anti-replay for a GDOI group, perform the following steps.
Note
SUMMARY STEPS
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
DETAILED STEPS
Configuring Passive SA
To configure Passive SA (to put the group member in passive mode), perform the following steps.
SUMMARY STEPS
1.
2.
3.
4.
5.
6.
DETAILED STEPS
Changing the Role of the Key Server
To change the role of the primary server to secondary server, perform the following steps.
SUMMARY STEPS
1.
2.
DETAILED STEPS
Setting Up a Group Member
To set up a group member, perform the following subtasks:
•
•
•
•
•
•
Setting Up the Group Name, ID, Key Server IP Address and Group Member registration
To set up the group name, ID, key server IP address and group member registration, perform the following steps.
Note
SUMMARY STEPS
1.
2.
3.
4.
or
identity address ipv4 address
5.
6.
DETAILED STEPS
What to Do Next
Set up the crypto map. See the section "Setting Up the Crypto Map" section.
Setting Up the Crypto Map
To set up the crypto map, perform the following steps.
SUMMARY STEPS
1.
2.
3.
4.
DETAILED STEPS
What to Do Next
Apply the crypto map to an interface to which the traffic has to be encrypted. See the "Applying the Crypto Map to an Interface to Which the Traffic Has to Be Encrypted" section.
Applying the Crypto Map to an Interface to Which the Traffic Has to Be Encrypted
To apply the crypto map to an interface to which the traffic has to be encrypted, perform the following steps.
SUMMARY STEPS
1.
2.
3.
4.
DETAILED STEPS
Configuring Fail-Close Mode
To configure a crypto map to work in fail-close mode, perform the following steps:
SUMMARY STEPS
1.
2.
3.
4.
5.
DETAILED STEPS
Configuring ciphers or hash algorithms for KEK
To configure acceptable ciphers or hash algorithms for KEK, perform the following steps.
SUMMARY STEPS
1.
2.
3.
4.
or
identity address ipv4 address
5.
6.
7.
8.
DETAILED STEPS
Configuring Acceptable Transform Sets for TEK
To configure the acceptable transform-tags used by TEK for data encryption or authentication, perform the following steps.
SUMMARY STEPS
1.
2.
3.
4.
5.
6.
7.
DETAILED STEPS
Verifying and Troubleshooting Cisco Group Encrypted Transport VPN
The following tasks can be used to verify and troubleshoot your GET VPN configurations. These tasks are optional and are used to gather information during troubleshooting.
•
•
•
•
•
•
Verifying Active Group Members on a Key Server
To verify active group members on a key server, perform the following steps.
SUMMARY STEPS
1.
2.
DETAILED STEPS
Verifying Rekey-Related Statistics
To verify rekey-related statistics, perform the following steps.
SUMMARY STEPS
1.
2.
DETAILED STEPS
Verifying IPsec SAs That Were Created by GDOI on a Group Member
To verify IPsec SAs that were created by GDOI on a group member, perform the following steps.
SUMMARY STEPS
1.
2.
DETAILED STEPS
Verifying IPsec SAs That Were Created by GDOI on a Key Server
To verify IPsec SAs that were created by GDOI on a key server, perform the following steps.
SUMMARY STEPS
1.
2.
DETAILED STEPS
Verifying Cooperative Key Server States and Statistics
To verify cooperative key server states and statistics, perform the following steps, using one or all of the debug and show commands shown.
SUMMARY STEPS
1.
2.
3.
DETAILED STEPS
Verifying Anti-Replay Pseudotime-Related Statistics
To verify anti-replay pseudotime-related statistics, perform the following steps using one or all of the clear, debug, and show commands.
SUMMARY STEPS
1.
2.
3.
4.
5.
DETAILED STEPS
Verifying the Fail-Close Mode Status of a Crypto Map
To verify the fail-close mode status of a crypto map, perform the following steps.
SUMMARY STEPS
1.
2.
DETAILED STEPS
Configuration Examples for Cisco Group Encrypted Transport VPN
This section includes the following case study and configuration examples:
•
Key Server and Group Member Case Study
The following case study includes encrypting traffic CE-CE in an MPLS VPN environment.
The MPLS VPN core interconnects VPN sites as is shown in Figure 12. VPN site CPEs, group member 1 through group member 4, are grouped into a single GDOI group that correlates with a VPN with which these sites are a part. This scenario is an intranet VPN scenario. All the key servers and group members are part of the same VPN. Key Server 1 and Key Server 2 are the cooperative key servers that support VPN members group member 1 through group member 4. Key Server 1 is the primary key server and Key Server 2 is the secondary key server.
Figure 12 Key Server and Group Member Scenario
The following configuration examples are based on the case study in Figure 12.
Key Server 1: Example
Key server 1 is the primary key server.
version 12.4service timestamps debug datetime msecservice timestamps log datetime msecno service password-encryptionservice internal!hostname KS1!logging buffered 100000 debuggingno logging console!no aaa new-model!resource policy!clock timezone EST 0ip subnet-zerono ip domain lookupip domain name cisco.com!crypto isakmp policy 1encr 3desauthentication pre-sharegroup 2lifetime 400crypto isakmp key cisco address 10.1.1.13crypto isakmp key cisco address 10.1.1.9crypto isakmp key cisco address 10.1.1.1crypto isakmp key cisco address 10.1.1.5crypto isakmp key cisco address 10.1.1.21!crypto ipsec transform-set gdoi-trans-group1 esp-3des esp-sha-hmac!crypto ipsec profile gdoi-profile-group1set security-association lifetime seconds 1800set transform-set gdoi-trans-group1!crypto gdoi group group1identity number 1server localrekey lifetime seconds 86400rekey retransmit 10 number 2rekey authentication mypubkey rsa group1-export-generalrekey transport unicastsa ipsec 1profile gdoi-profile-group1match address ipv4 101replay counter window-size 64address ipv4 209.165.200.225redundancylocal priority 10peer address ipv4 209.165.200.225!interface Ethernet0/0ip address 209.165.200.225 255.255.255.252!ip classlessip route 0.0.0.0 0.0.0.0 10.1.1.18!access-list 101 permit ip 10.1.0.0 0.0.255.255 10.1.0.0 0.0.255.255!endKey Server 2: Example
Key Server 2 is the secondary key server.
version 12.4service timestamps debug datetime msecservice timestamps log datetime msecno service password-encryptionservice internal!hostname KS2!logging buffered 100000 debuggingno logging console!no aaa new-model!resource policy!clock timezone EST 0ip subnet-zerono ip domain lookupip domain name cisco!crypto isakmp policy 1encr 3desauthentication pre-sharegroup 2lifetime 400crypto isakmp key cisco address 10.1.1.9crypto isakmp key cisco address 10.1.1.1crypto isakmp key cisco address 10.1.1.5crypto isakmp key cisco address 10.1.1.17crypto isakmp key cisco address 10.1.1.13!crypto ipsec transform-set gdoi-trans-group1 esp-3des esp-sha-hmac!crypto ipsec profile gdoi-profile-group1set security-association lifetime seconds 1800set transform-set gdoi-trans-group1!crypto gdoi group group1identity number 1server localrekey lifetime seconds 86400rekey retransmit 10 number 2rekey authentication mypubkey rsa group1-export-generalrekey transport unicastsa ipsec 1profile gdoi-profile-group1match address ipv4 101replay counter window-size 64address ipv4 10.1.1.21redundancylocal priority 1peer address ipv4 10.1.1.17!interface Ethernet0/0ip address 209.165.200.225 255.255.255.252!ip classlessip route 0.0.0.0 0.0.0.0 10.1.1.22!access-list 101 permit ip 10.1.0.0 0.0.255.255 10.1.0.0 0.0.255.255!endGroup Member 1: Example
Group member 1 is part of a GDOI group that correlates with a VPN with which these sites are a part.
version 12.4service timestamps debug datetime msecservice timestamps log datetime msecno service password-encryption!hostname GM1!resource policy!clock timezone EST 0ip subnet-zero!crypto isakmp policy 1encr 3desauthentication pre-sharegroup 2lifetime 3600crypto isakmp key cisco address 209.165.200.225crypto isakmp key cisco address 209.165.201.1!crypto gdoi group group1identity number 1server address ipv4 209.165.200.225server address ipv4 209.165.201.1!crypto map map-group1 10 gdoiset group group1!interface Ethernet0/0ip address 209.165.200.225 255.255.255.252crypto map map-group1!router bgp 1000no synchronizationbgp log-neighbor-changesnetwork 10.1.1.0 mask 255.255.255.0neighbor 10.1.1.2 remote-as 5000no auto-summary!ip classless!EndThe same GDOI group cannot be applied to multiple interfaces. The following examples show unsupported cases:Example 1
crypto map map-group1group g1interface ethernet 1/0crypto map map-group1interface ethernet 2/0crypto map map-group1Example 2
crypto map map-group1 10 gdoiset group group1crypto map map-group2 10 gdoiset group group1interface ethernet 1/0crypto map map-group1interface ethernet 2/0Group Member 2: Example
Group member 2 is part of a GDOI group that correlates with a VPN with which these sites are a part.
version 12.4service timestamps debug datetime msecservice timestamps log datetime msec!hostname GM2!resource policy!clock timezone EST 0ip subnet-zero!crypto isakmp policy 1encr 3desauthentication pre-sharegroup 2lifetime 3600crypto isakmp key cisco address 209.165.200.225crypto isakmp key cisco address 209.165.201.1!crypto gdoi group group1identity number 1server address ipv4 209.165.201.1server address ipv4 209.165.200.225!crypto map map-group1 10 gdoiset group group1!interface Ethernet0/0ip address 209.165.200.225 255.255.255.252crypto map map-group1!router bgp 2000no synchronizationbgp log-neighbor-changesnetwork 10.1.2.0 mask 255.255.255.0neighbor 10.1.1.6 remote-as 5000no auto-summary!ip classless!endGroup Member 3: Example
Group member 3 is part of a GDOI group that correlates with a VPN with which these sites are a part.
version 12.4service timestamps debug datetime msecservice timestamps log datetime msecno service password-encryption!hostname GM3!resource policy!clock timezone EST 0ip subnet-zero!crypto isakmp policy 1encr 3desauthentication pre-sharegroup 2lifetime 3600crypto isakmp key cisco address 209.165.200.225crypto isakmp key cisco address 209.165.201.1!crypto ipsec transform-set gdoi-trans-group1 esp-3des esp-sha-hmaccrypto gdoi group group1identity number 1server address ipv4 209.165.200.225server address ipv4 209.165.201.1!crypto map map-group1 10 gdoiset group group1!interface Ethernet0/0ip address 209.165.201.1 255.255.255.252crypto map map-group1!router bgp 3000no synchronizationbgp log-neighbor-changesnetwork 10.1.3.0 mask 255.255.255.0neighbor 10.1.1.10 remote-as 5000no auto-summary!ip classless!endGroup Member 4: Example
Group member 4 is part of a GDOI group that correlates with a VPN with which these sites are a part.
version 12.4service timestamps debug datetime msecservice timestamps log datetime msecno service password-encryption!hostname GM4!clock timezone EST 0ip subnet-zero!crypto isakmp policy 1encr 3desauthentication pre-sharegroup 2lifetime 3600crypto isakmp key cisco address 209.165.200.225crypto isakmp key cisco address 209.165.201.1!crypto gdoi group group1identity number 1server address ipv4 209.165.200.225server address ipv4 209.165.201.1!crypto map map-group1 10 gdoiset group group1!interface Ethernet0/0ip address 209.165.201.1 255.255.255.252crypto map map-group1!router bgp 4000no synchronizationbgp log-neighbor-changesnetwork 10.1.4.0 mask 255.255.255.0neighbor 10.1.1.14 remote-as 5000no auto-summary!ip classless!endGroup Member 5: Example
If a group member has multiple interfaces that are part of the same GDOI group, it is recommended that a loopback interface is used to source the crypto. If a loopback interface is not used, each interface that handles encrypted traffic must register individually with the key server.
The key server sees these as separate requests and must keep multiple records for the same group member, which also means sending multiple rekeys. If crypto is sourced from the loopback interface instead, the group member registers only once with the key server.
The following configuration shows how the group member registers once with the key server:
!
interface GigabitEthernet0/1description *** To AGG-1 ***crypto map dgvpn!interface GigabitEthernet0/2description *** To AGG-2 ***crypto map dgvpn!interface Loopback0ip address 209.165.201.1 255.255.255.255!crypto map dgvpn local-address Loopback0!Passive SA: Example
The following output example displays information about crypto rules on outgoing packets:
Router# show crypto rulesetEthernet0/0:59 ANY ANY DENY11 ANY/848 ANY/848 DENYIP ANY ANY IPSec SA PassiveIP ANY ANY IPSec CryptomapThe following output example displays the directional mode of the IPsec SA:
Router# show crypto ruleset detailEthernet0/0:20000001000019 59 ANY ANY DENY -> 2000000199999920000001000029 11 ANY/848 ANY/848 DENY -> 2000000199999920000001000035 IP ANY ANY IPSec SA Passive20000001000039 IP ANY ANY IPSec CryptomapFail-Close Mode: Examples
The following example shows that fail-close mode has been activated, and unencrypted traffic from access list 102 is allowed before the group member is registered:
crypto map map1 gdoi fail-closematch address 102activatecrypto map map1 10 gdoiset group ks1_groupmatch address 101!access-list 101 deny ip 10.0.1.0 0.0.0.255 10.0.1.0 0.0.0.255access-list 102 deny tcp any eq telnet any
The following show crypto map gdoi fail-close command output shows that fail-close has been activated:
Router# show crypto map gdoi fail-closeCrypto Map: "svn"Activate: yesFail-Close Access-List: (Deny = Forward In Clear, Permit = Drop)access-list 105 deny tcp any port = 23 anyaccess-list 105 deny ospf any anyAdditional References
The following sections provide references related to the Cisco Group Encrypted Transport VPN feature.
Related Documents
Cisco IOS commands (listed in an index)
Cisco IOS Master Commands List, All Releases
Cisco IOS security commands
Configuring IKE and IKE policy
Configuring an IPsec transform
Standards
No new or modified standards are supported, and support for existing standards has not been modified.
—
MIBs
RFCs
Technical Assistance
Feature Information for Cisco Group Encrypted Transport VPN
Table 3 lists the features in this module and provides links to specific configuration information.
Use Cisco Feature Navigator to find information about platform support and software image support. Cisco Feature Navigator enables you to determine which Cisco IOS and Catalyst OS software images support a specific software release, feature set, or platform. To access Cisco Feature Navigator, go to http://tools.cisco.com/ITDIT/CFN/jsp/index.jsp. An account on Cisco.com is not required.
Note
Table 3 Feature Information for Cisco Group Encrypted Transport VPN
Secure Multicast
12.4(6)T
The secure multicast part of this feature was first introduced in Cisco IOS Release 12.4(6)T in Secure Multicast. However, all pertinent information from that document has been integrated and updated in this current document (Cisco Group Encrypted Transport VPN).
Cisco Group Encrypted Transport VPN
12.4(11)T
Cisco Group Encrypted Transport VPN is an optimal encryption solution for large-scale IP or MPLS sites that require any-to-any connectivity with minimum convergence time, low processing, provisioning, managing, and troubleshooting overhead.
The following commands were introduced or modified: address ipv4 (GDOI), clear crypto gdoi, crypto gdoi gm, debug crypto gdoi, local priority, peer address ipv4, redundancy, rekey address ipv4, rekey transport unicast, replay counter window-size, replay time window-size, sa receive-only, show crypto gdoi.
VSA Support for GET VPN
12.4(15)T5
Cisco VSA (high-performance crypto engine) support was added for GDOI and GET VPN.
Note
GET VPN Phase 1.2
12.4(22)T
Support for time-based anti-replay on the Cisco VSA was added in Cisco IOS Release 12.4(22)T.
GET VPN Enhancements
12.4(22)T
These enhancements include the following features:
•
This feature enables you to change the role of the key server from primary to secondary.
The following sections provide information about this feature:
–
•
This feature prevents unencrypted traffic from passing through the group member before that member is registered.
The following sections provide information about this feature:
–
The following commands were added or modified for this feature: activate, crypto map, match address, show crypto map.
clear crypto gdoi ks cooperative role
•
This feature allows a group member to be configured into passive mode permanently.
The following sections provide information about this feature:
The following command was added by this feature: passive.
GET VPN VRF-Aware GDOI on GM
Cisco IOS Release 15.0(1)M
This feature enhances GET VPN, it allows separation between Data and Control planes on Group Members.
The following commands were introduced or modified:
client registration interface.
Glossary
DOI—Domain of Interpretation. For Internet Security Association Key Management Protocol (ISAKMP), a value in the security association (SA) payload that describes in which context the key management message is being sent (IPsec or Group Domain of Interpretation).
GDOI—Group Domain of Interpretation. For ISAKMP, a means of distributing and managing keys for groups of mutually trusted systems.
group member—Device (Cisco IOS router) that registers with a group that is controlled by the key server for purposes of communicating with other group members.
group security association—SA that is shared by all group members in a group.
IPsec—IP security. Data encryption protocol for IP packets that are defined in a set of RFCs (see IEEE RFC 2401).
ISAKMP—Internet Security Association and Key Management Protocol. Protocol that provides a framework for cryptographic key management protocols.
KEK—key encryption key. Key used to protect the rekey between the key server and group members.
key server—Device (Cisco IOS router) that distributes keys and policies to group members.
MTU—maximum transmission unit. Size (in bytes) of the largest packet or frame that a given layer of a communications protocol can pass onward.
SA—security association. SA that is shared by all group members in a group.
TEK—traffic encryption key. Key that is used to protect the rekey between group members.
Appendix I: System Messages
Table 4 lists GET VPN system messages and explanations.
CCDE, CCENT, CCSI, Cisco Eos, Cisco HealthPresence, Cisco IronPort, the Cisco logo, Cisco Nurse Connect, Cisco Pulse, Cisco SensorBase, Cisco StackPower, Cisco StadiumVision, Cisco TelePresence, Cisco Unified Computing System, Cisco WebEx, DCE, Flip Channels, Flip for Good, Flip Mino, Flipshare (Design), Flip Ultra, Flip Video, Flip Video (Design), Instant Broadband, and Welcome to the Human Network are trademarks; Changing the Way We Work, Live, Play, and Learn, Cisco Capital, Cisco Capital (Design), Cisco:Financed (Stylized), Cisco Store, Flip Gift Card, and One Million Acts of Green are service marks; and Access Registrar, Aironet, AllTouch, AsyncOS, Bringing the Meeting To You, Catalyst, CCDA, CCDP, CCIE, CCIP, CCNA, CCNP, CCSP, CCVP, Cisco, the Cisco Certified Internetwork Expert logo, Cisco IOS, Cisco Lumin, Cisco Nexus, Cisco Press, Cisco Systems, Cisco Systems Capital, the Cisco Systems logo, Cisco Unity, Collaboration Without Limitation, Continuum, EtherFast, EtherSwitch, Event Center, Explorer, Follow Me Browsing, GainMaker, iLYNX, IOS, iPhone, IronPort, the IronPort logo, Laser Link, LightStream, Linksys, MeetingPlace, MeetingPlace Chime Sound, MGX, Networkers, Networking Academy, PCNow, PIX, PowerKEY, PowerPanels, PowerTV, PowerTV (Design), PowerVu, Prisma, ProConnect, ROSA, SenderBase, SMARTnet, Spectrum Expert, StackWise, WebEx, and the WebEx logo are registered trademarks of Cisco Systems, Inc. and/or its affiliates in the United States and certain other countries.
All other trademarks mentioned in this document or website are the property of their respective owners. The use of the word partner does not imply a partnership relationship between Cisco and any other company. (0910R)
Any Internet Protocol (IP) addresses and phone numbers used in this document are not intended to be actual addresses and phone numbers. Any examples, command display output, network topology diagrams, and other figures included in the document are shown for illustrative purposes only. Any use of actual IP addresses or phone numbers in illustrative content is unintentional and coincidental..
©2006-2009 Cisco Systems, Inc. All rights reserved.
