Group Encrypted Transport VPN (Get VPN) Design and Implementation Guide

Transcript

1 Group Encrypted Transport VPN (GETVPN) Design and Implementation Guide Haseeb Niazi, Nipul Shah, Biao Zhou, Varun Sethi Shashi Shastry, Rudresh Veerappaji August 2018 February 2010 1 Page 220 of © 2018 Cisco Systems, Inc. Cisco Confidential/Proprietary GETVPN Design and Implementation Guide

2 Contents About Group Encrypted Transport Virtual Private Networks ... ... 3 1. ... ... ... ... 4 1.1 Key GETVPN Benefits ... ... 1.2 Technology Overview ... 4 ... 1.3 GETVPN Solution Positioning ... ... ... . 9 1.4 GET ... ... ... 10 VPN Solution Comparison 1.5 Further Reading ... ... ... ... 11 ... 2. ... ... GETVPN Configuration ... 12 2.1 Implementing GETVPN ... ... ... ... 12 2.2 KS Configuration ... ... ... ... 13 ... ... ... ... 22 2.3 GM Configuration 23 2.4 COOP KS Configuration ... ... ... ... 2.5 G - ... ... ... ... 27 IKEv2 Configuration - B Support for GETVPN ... ... ... 30 2.6 Suite 3. GETVPNSystem Design ... ... ... ... 31 3.1 Platform Support ... ... ... ... 31 ... 3.2 IOS Software Releases ... ... ... 31 3.3 KS Selection ... ... ... 32 ... 3.4 GM Selection ... ... ... ... 32 3.5 KS Design Conside rations ... ... ... ... 33 3.6 GM Design Considerations ... ... ... .. 46 3.7 COOP Design Considerations ... ... ... 56 89 3.8 Designing Around MTU Issues ... ... ... Aware GETVPN - 3.9 VRF 90 ... ... ... ... 3.10 GETVPN Support for IPv6 in the Data Plane ... 100 ... ... ... 103 ... 3.11 GETVPN Support for LISP ... ... ... ... 105 3.12 GETVPN GDOI Bypass ... VPN Routing Awareness ... ... ... 105 3.13 GET ... 106 ... 3.14 IPsec Inline Tagging for Cisco TrustSec on GETVPN ... ... ... 3.15 GETVPN Software versioning 108 3.16 GM Removal and Policy Replacement ... ... ... 111 ... 4. ... ... Enterprise Deployment ... 116 4.1 DC and Branch Designs ... ... ... ... 116 4.2 DC Design ... ... ... ... 118 ... ... ... ... 131 4.3 Branch Design 4.4 Deploying GETVPN ... ... ... ... 159 Provisioning, Verification, and Monitoring 165 ... ... 5. ... 5.1 Deploying GETVPN using CSM ... ... 165 ... 5.2 GETVPN Syslog Capabilities ... ... ... 173 5.3 GDOI Event Trace ... ... ... ... 176 5.4 GETVPN Veri ... ... ... ... 178 fication 5.5 SNMP Monitoring using GDOI MIB ... ... ... 191 Appendix A. Complete Configurations for Section 2 ... ... 196 Shared Keys - A.1 Using Pre ... ... ... ... 199 A.2 Using Public Key Infrastructure (PKI) ... ... 203 ... rtificate Authority A.3 IOS Ce ... ... ... ... 207 A.4 G - IKEv2 Configuration Using PKI ... ... ... 209 Appendix B. Steps to upgrade Key Servers and Group Members ... ... 214 ... ... 215 Appendix C. Steps to change RSA Keys on Key Servers ... ... 217 ... Appendix D. Recent Features and Enhancements ... ... Appendix E. Abbreviations and Acronyms 218 ... of Page 2 220 © 2018 Cisco Systems, Inc. Cisco Confidential/Proprietary GETVPN Design and Implementation Guide

3 oup Encrypted Transport Virtual 1. About Gr Networks Private Networks have become critical strategic assets and lifelines for running successful enterprises. Today‘s networks not only support critical applications, but also support voice and video infrastructures. Applications over IP, now require instantaneous and technologies, such as distributed computing and voice and video - branch mmunication. Because of these requirements, the traditional hub spoke topology of - and - branch co - to any connectivity model - to enterprise networks is no longer sufficient. Enterprises must implement the any - te LAN services (VPLS) networks. provided by IP virtual private networks (VPNs) and virtual priva Although IP VPN and VPLS services built with Multiprotocol Label Switching (MPLS) separate enterprise traffic from the public Internet to provide some security, in recent years government regulations, such as Leach Health Insuran ce Portability and Accountability Act (HIPAA), Gramm - - Bliley Act (GLBA), and Payment Card Industry Data Security Standard (PCI DSS), mandate encryption even over private IP networks. to - - s r exa ite IPsec, Site Cisco IOS offers several IPsec tunnel - based encryption solutions (fo mple, IPsec/generic routing encapsulation (GRE), and Dynamic Multipoint VPN (DMVPN) that can be deployed - based encryption solutions are point - - to over an MPLS VPN, VPLS or shared IP networks. Traditional tunnel point. based solutions require the - rue full mesh or even dense partial mesh of connectivity, tunnel To provide a t provisioning of a complex connectivity mesh. Such a complex mesh not only has higher processor and memory requirements, but is difficult to provision, troubleshoot , and manage. Some provisioning overhead can be reduced using DMVPN. However, DMVPN requires overlaying a secondary routing infrastructure through the tunnels, which results in suboptimal routing while the dynamic tunnels are built. The overlay ology also reduces the inherent scalability of the underlying IP VPN network topology. routing top - to - point IPsec tunneling solutions suffer from multicast replication issues because multicast Traditional point and encryption at the IPsec CE (customer edge) replication must be performed before tunnel encapsulation router closest to the multicast source. Multicast replication cannot be pe rformed in the provider network because encapsulated multica sts appear to the core network as unicast data. eliminate Cisco‘s Group Encrypted Tr GETVPN ) introduces the concept of a trusted group to ansport VPN ( point - to - point tunnels and their associated overlay routing. All group members (GMs) share a common traffic that was encrypted security association (SA), also known as a group SA. This enables GMs to decrypt by any other GM. (Note that IPsec CE acts as a GM.) In GETVPN networks, there is no need to negotiate - is ―tunnel to less.‖ point - GETVPN - point IPsec tunnels between the members of a group, because - 6407 Group Domain of Interpretation (GDOI) is an integral part of The IETF standard RFC GETVPN first . The GDOI protocol was introduced in 12.4(2)T but the GETVPN solution has had several IKE - The G . See 1.2.1, ―GDOI,‖ for more information about GDOI. enhancements over the newer releases v2 and Cisco IOS Release 15.5(1)S. See 1.2.9 )T was introduced In Cisco IOS Release 15.5(1 protocol VPN G GET ― IKEv2. - IKEv2,‖ for more information about G - of Page 3 220 © 2018 Cisco Systems, Inc. Cisco Confidential/Proprietary GETVPN Design and Implementation Guide

4 1.1 Key GETVPN Benefits GETVPN provides the following key benefits: ● scale any - Instantaneous large ny IP connectivity using a group IPsec security paradigm a - to - ● Takes advantage of underlying IP VPN routing infrastructure and does not require an overlay routing control plane ● n issues typically Seamlessly integrates with multicast infrastructures without the multicast replicatio based IPsec solutions. - seen in traditional tunnel ● Preserves the IP source and destination addresses during the IPsec encryption and encapsulation ery well with features such as QoS and traffic engin GETVPN eering. process. Therefore , integrates v 1.2 Technology Overview The solution is based on both open standards and Cisco patented innovative technology which GETVPN helps utilize the power of underlying MPLS/shared IP networks. In addition to leveraging the existing IKE, IPsec and multicas solution relies on following core building blocks to provide the GETVPN t technologies, required functionality: ● 6407 GDOI (RFC ) ● Key servers (KSs) ● Cooperative (COOP) KSs ● ) G Ms roup Members (G ● IP tunnel header preservation ● Group security association ● Rekey mech anism ● Time replay (TBAR) - based anti - ● IKEv2 G - ● IP - D3P 1.2.1 GDOI The GDOI group key management protocol is used to provide a set of cryptographic keys and policies to a roup of GETVPN group of devices. In a network, GDOI is used to distribute common IPsec keys to a g enterprise VPN gateways that must communicate securely. These keys are periodically refreshed and are updated on all the VPN gateways using a process called ―rekey.‖ g VPN gateways must The GDOI protocol is protected by Internet Key Exchange (IKE) SA. All participatin authenticate themselves to the device providing keys using IKE. All IKE authentication methods, for example, pre shared keys (PSKs) and public key infrastructure (PKI) are supported for initial authentication. - After the VPN gateways are authenticated and provided with the appropriate security keys via the IKE SA, the IKE SA expires and GDOI is used to update the GMs in a more scalable and efficient manner. For more 6407 . information about GDOI, refer to RFC control plane; the other key GETVPN encryption keys. One key secures the GDOI introduces two different secures the data traffic. The key used to secure the control plane is commonly called the Key Encryption Key (KEK), and the key used to encrypt data traffic is known as Traffic Encryp tion Key (TEK). of Page 4 220 © 2018 Cisco Systems, Inc. Cisco Confidential/Proprietary GETVPN Design and Implementation Guide

5 1.2.2 Tunnel Header Preservation packet In traditional IPsec, tunnel endpoint addresses are used as new packet source and destination. The crypting is then routed over the IP infrastructure, using the encrypting gateway source IP address and the de GETVPN , IPsec protected data packets encapsulate the gateway destination IP address. In the case of original source and destination packet addresses of the host in the outer IP header to ―preserve‖ the IP address. Tunnel Header Preservation Figure 1. biggest advantage of tunnel header preservation is the ability to route encrypted packets using the The underlying network routing infrastructure. The branch high availability (HA) provided by the IP, VPLS, or and so on) integrates seamlessly with the MPLS VPN infrastructure (dual spokes, dual links, GETVPN solution. There is no need to provide HA at the IPsec level (dual hubs, stateful IPsec HA, and so on). Because tunnel header preservation is combined with group SAs, multicast replication can be offloaded to the provider network. Because every GM shares the same SA, the IPsec router closest to the multicast source does not need to replicate packets to all its peers, and is no longer subject to multicast replication issues seen in traditional IPsec solutions. It is worth noting that tunnel header preservation seems very similar to IPsec transport mode. Note: However, the underlying IPsec mode of operation with GETVPN is IPsec tunnel mode. While IPsec transport s overhead to an IP packet (5% for IMIX packets; mode reuses the original IP header and therefore adds les 1% for 1400 - byte packets), IPsec transport mode suffers from fragmentation and reassembly limitations when used together with Tunnel Header Preservation and must not be used in GETVPN deployments where encry pted or clear packets might require fragmentation. 2 GETVPN - solution is very well suited for MPLS, Layer Note: Because of tunnel header preservation, is generally not a good GETVPN (L2), or an IP infrastructure with end to end IP connectivity. However, for deployment over the Internet because enterprise host IP addresses candidate are typically not routable, with tunnel header preservation. tion (NAT) functions interfere network address transla and 1.2.3 Key Servers ( KSs ) control plane. All A key server (KS) is a device responsible for creating and maintaining the GETVPN encryption policies, such as interesting traffic, encryption protocols, security association, rekey timers, and so on, are centrally defined on the KS and are pushed down to all GMs at registration time. encryption policies and shared keys or PKI) and download the - GMs authenticate with the KS using IKE (pre GETVPN keys required for operation. The KS is also responsible for refreshing and distributing the keys. of Page 5 220 © 2018 Cisco Systems, Inc. Cisco Confidential/Proprietary GETVPN Design and Implementation Guide

6 Unlike traditional IPsec, interesting t raffic defined on the KS (using an access control list (ACL)) irrespective of downloaded to every GM, is the GM owns that network. It is recommended to summarize GM networks into as few entries as possible, and to strive for a symmetric policy. For example , if all LAN addresses on the GMs are within the 10.0.0.0/8 network (10.1.1.0/24, 10.1.2.0/24, and so on), it is better to opposed to ―permit 10.1.1.0/24 to define interesting traffic as ―permit 10.0.0.0/8 to 10.0.0.0/8‖ as 10.1.2.0/24‖, ―10.1.1.0/24 to 10 .1.3.0/24,‖and so on. Asymmetric policies lead to a geometric expansion in the number of ACL entries. An aggregate policy that serves the most GMs is ideal. The most complete aggregate policy is permit ip any any. This policy encrypts he GM crypto interface. Therefore, exceptions must be made (that is, deny entries) to all traffic leaving t exclude encryption of control plane traffic and management plane necessary to bootstrap the GM. Note: A device acting as a KS cannot be configured as a GM ) GMs ers ( b Group Mem 1.2.4 responsible for actual encryption and decryption i.e. a device responsible to handle device A GM is a data plane. A GM is only configured with IKE parameters and KS/Group information. As GETVPN mentioned before, encryption policies are defined central ly on the KS and downloaded to the GM at the time of registration. Based on these downloaded policies, GM decides whether traffic needs to be encrypted or but in some GETVPN network, GM policies are dictated by the KS , decrypted and what keys to use. In a instances, a GM can be configured to locally override some of these policies. Any global policy (including both permit and deny entries) defined on the KS affects all the members of the group whether it is applicable to them or not and therefore some polic ies make more sense when defined locally. As an example, if a in the group are running a different routing protocol, a local entry can be added to these handful of GMs to bypass encryption of the routing protocol traffic instead of defining the policy globally GMs at the KS level. 1.2.5 Group SA Unlike traditional IPsec encryption solutions, GETVPN uses the concept of group SA. All members in the GETVPN group can communicate with each other using a common encryption policy and a shared SA. With a common en cryption policy and a shared SA, there is no need to negotiate IPsec between GMs; this reduces the resource load on the IPsec routers. Traditional GM scalability (number of tunnels and GMs. GETVPN associated SA) does not apply to Note: 00 ACL entries can be used to define interesting (permit and deny) group, up to 1 GETVPN In a KS is 70 size ACL VPN card is used on Cisco ISR G2, the recommended - If an ISM traffic for encryption. entries, whereas it . ACL exception for local entries is 32 on GM to summarize interesting traffic to as few permit entries as possible, and to build It is a best practice Unlike traditional IPSec policy symmetric policies. , where source and destination address ranges must be GETVPN is optimized when the source and destinati on address range are the same. This uniquely defined, very efficient. GETVPN minimizes the number of policy permutations, making 1.2.6 Rekey Process As mentioned above, the KS is not only responsible for creating the encryption policies and keys, but also for refreshing key s and distribute them to GMs. The process of sending out new keys when existing keys are of Page 6 220 © 2018 Cisco Systems, Inc. Cisco Confidential/Proprietary GETVPN Design and Implementation Guide

7 about to expire, is known as the rekey process. supports two types of rekey messages: unicast GETVPN and multicast. If a GM does not receive rekey information from the KS (for example, the KS is down or network connectivity when only 5% of the original TEK lifetime is broken), the GM tries to reregister to an ordered set of KSs remains. Registration must be completed 30 seconds before the existing IPsec SAs expire ‘s that as GM - registered will start using the new IPSec SA when 30 seconds have successfully received rekey or re over period for traffic - remain in the previous TEK‘s lifetime. The 30 second window provides a graceful roll r the network before the deletion of the expiring TEK encrypted with the previous TEK to clea . If reregistration is successful, the GM receives new SAs as part of the reregistration process and traffic in the data plane S is unavailable), the GM tries three flows without disruption. If reregistration is unsuccessful (the preferred K - second intervals, to establish a connection with the KS. If all attempts to contact the more times, at 10 The process repeats through each of the preferred KS fail, the GM tries the next KS in the ordered list. set of KS until all KS have been attempted. The GM will restart the registration process to the first ordered KS in the ordered set until registration is successful. Note: for SA setup using GETVPN crypto maps. based rekey is disabled - Volume 1.2.6.1 Unicast Rekey e unicast rekey process, a KS generates a rekey messag In th e and sends multiple copies of the message, one copy to each GM. Upon receiving the rekey message, a GM sends an ACK message to the KS. This ACK mechanism not only ensures that the list of active GMs on he KS t is current, but also ensures that the only once to GM‘s that successfully receive the rekey and the KS only to active GMs. rekey message is sent GM A KS can be configured to retransmit a rekey packet to overcome transient defects in the network. If a scheduled rekeys, the KS removes the GM from its active GM does not acknowledge three consecutive database and stops sending rekey messages to that GM. Note: Unicast rekey retransmission occurs only when a GM does not ACK a rekey. 1.2.6.2 Multicast Rekey he multicast rekey process, a KS generates a rekey message and sends one copy of the message to a In t multicast group address that is predefined in the configuration. Each GM joins the multicast group at registration time, so each GM receives a copy of the rek ey message. Unlike unicast rekey, multicast rekey does not have an ACK mechanism. The KS does not maintain a list of active GMs. Multicast rekey uses the same low CPU overhead whether there is one GM in the group or a KS can be configured to retransmit a multicast rekey packet to few thousand. Just like unicast rekey, overcome transient network defects. GETVPN Multicast must be enabled in the core network for multicast rekey to work in the control Note: plane. 1.2.7 COOP KSs GETVPN the The KS is the most important entity in network because the KS maintains the control plane. VPN network. Because redundancy is an - GET Therefore, a single KS is a single point of failure for an entire VPN supports multiple KSs, called cooperative ( - GET important consideration for KSs, COOP) KSs, to ensure seamless fault recovery if a KS fails or becomes unreachable. of Page 7 220 © 2018 Cisco Systems, Inc. Cisco Confidential/Proprietary GETVPN Design and Implementation Guide

8 all COOP KSs. GM configuration A GM can be configured to register to any available KS from a list of determines the registration order. The KS defined first is contacted fir s t, followed by the second defined KS, and so on. Note: The COOP protocol is configured on a per GDOI group basis. A KS that is configured with multiple GDOI groups can maintain multiple unique COOP relationships with disparate KSs. ssume a ―secondary‖ role and begin an election process. One KS, typically When COOP KSs boot, all KSs a the one having the highest priority, is elected as a ―primary‖ KS. The other KSs remain in the secondary group policies to all GMs, gured confi and distributing keys state. The primary KS is responsible for creating and to periodically synchronize the COOP KSs. Note: GMs can register to any available KS (primary or secondary), but only the primary KS sends rekey to reduce the IKE to distribute GM registration to all available COOP KSs possible messages. It is processing load on a single KS. See 3.7.3.3, ―Balancing GM Registrations among COOP KSs,‖ for details. - way announcement messages (primary to secondary) on a 20 second Cooperative KSs exchange one from the primary KS . If a secondary KS does not hear interval , the secondary over a 30 second interval tries to contact the primary KS and requests updated information. If the secondary KS does not hear KS process from the primary KS new primary is triggered and a , a COOP reelection over a 60 second interval KS is elected. Up to eight KSs can be defined as COOP KSs, but more than four COOP servers are seldom required. Since rekey information is generated and distributed from a single primary KS, the advantage of deploying more than two KSs is the ability to handle registration load in case of a network failure and reregistration taking place at the same time. This is especially important when using Public Key Infrastructure (PKI) because IKE negotiation using PKI requires a lot more CPU power compa red to IKE negotiation using pre - shared keys (PSKs). Tip : Periodic DPD must be enabled on the ISAKMP SAs between the KSs if COOP is configured. This way primary KS can track and display the state of the other secondary KSs. the Periodic DPD between GM and KS is not required. (TBAR) Replay 1.2.8 Time Based Anti - replay capabilities prevent a malicious third party from capturing IPsec In traditional IPsec solutions, anti - packets and relaying those packets at a later time to launch a denial of service attack ag ainst the IPsec based sliding window protocol: The sender sends counter - endpoints. These traditional IPsec solutions use a a packet with a sequence number, and the receiver uses the sliding window to determine whether a packet is acceptable, or has arrived out - of - sequence and is outside the window of acceptable packets. , counter - based anti replay is ineffective. A new method to guard Because we use the group SA in GETVPN - GET replay (TBAR), which i - based anti against replay - attacks is required. s based on a - VPN uses time - - pseudo time clock that is maintained on the KS. An advantage of using pseudotime for TBAR is that there is GETVPN no need to synchronize time on all the devices using NTP. The primary KS is responsible for establishing and maintaining the pseu time for a group. The primary KS - do must also keep pseudotime synchronized on all GMs via rekey updates , which by default is sent every 7200 - . Every GM includes its pseudo or 2 hours seconds time as a time stamp in the data packets. A receiving of Page 8 220 © 2018 Cisco Systems, Inc. Cisco Confidential/Proprietary GETVPN Design and Implementation Guide

9 VPN gateway then compares time stamp of the received packet with the GM reference pseudotime clock it maintains for the group. If the packet arrived too late, it is dropped. Figure 2. Time Based Anti - Replay d so on). While the threat of anti GET - VPN is typically deployed over a private WAN (VPLS, MPLS, an Tip: - replay attack is minimal, it is a best practice to enable TBAR. TBAR is enabled group wide on the KS. 1.2.9 GET IKEv2 VPN G - ons Internet Key Exchange Version 2 (IKEv2) provides improvisations to ISAKMP infrastructure with less learned from the industry. IKEv2 reduces network latency, reduces complexity in message exchanges, improves interoperability and reliability, and fixes cryptographic issue in HASH authentication. GETVPN combines IKEv2 protocol with IPsec to provide an efficient method to secure IP multicast traffic or unicast traffic through the GETVPN G - IKEv2 feature. This feature provides a complete IKEv2 solution across all of Cisco‘s VPN technologies. The G - IKEv2 protocol provides a mechanism for a group member (G M) to download policy and keys from a key server (KS). These policy and keys are used to secure communication among GMs in a group. G - IKEv2 is a new model to secure group communication between remote locations in an enterprise private WAN. GETVPN GETVPN GETVPN Interoperability 10 . 2 . 1 D3P - IP — D3P, enabled on - - D3P feature implements IP Delivery Delay Detection Protocol on Cisco software. IP The IP the crypto data plane, uses the system clock of the GMs to create or verify the IP - D3P datagram‘s timestamp. In m any cases, the system clock is set from an external protocol, for example, Network Time Protocol, to maximize the likelihood that the system clocks of both sender and receiver are synchronized. IP datagrams are subject to delivery delay attack, in which a host or gateway receives datagrams that are - D3P datagram consists of a header and an IP payload. The IP not fresh. IP D3P header includes a - timestamp, which receivers of the packet use to determine whether or not the packet has been recently generated. Re ceivers compare the timestamp delivered in the IP packet to their local time and decide if the IP packet must be accepted. are C onfigurations and verification with examples for the GETVPN Interoperability — IP - D3P feature VPN Configuration Guide GET described in . GETVPN Solution Positioning 1.3 solution. GETVPN the positioning of the 3 illustrates Figure of 220 Page 9 © 2018 Cisco Systems, Inc. Cisco Confidential/Proprietary GETVPN Design and Implementation Guide

10 GET Figure 3. VPN Solution Positioning GETVPN is well suited for deployments over private WAN networks, allowing the utilization of As noted, GETVPN is not well suited for deployment underlying MPLS/shared IP networks using header preservation. tunnel - over the Internet, so a FlexVPN, or Site - to - Site VPNs should based IPsec solution such as DMVPN, be deployed over the Internet. 1.4 GETVPN Solution Comparison Table 1 provides a basic comparison of DMVPN , FlexVPN and GETVPN technologies. Consult the detailed documentation about these technologies for further information. Table 1. GETVPN Solution Comparison Solution DMVPN FlexVPN GET VPN Infrastructure Network Public Internet Transport Public Internet Transport Private IP Transport Spoke; - Site) - to - Any; (Site - to - Any Network Style Hub - Spoke and Spoke - to - to - Spoke Spoke and - Hub and Site to - e Spoke; (Sit Site) (Client - to - Site - - to - Site ) Dynamic routing on IP WAN Dynamic routing on tunnels or on routing Dynamic Routing IKEv2 routing or IKEv2 Dynamic tunnels routing R Failover Redundancy oute Distribution Model Route Distribution Model Route Distribution Model Encryption Style to Group Protection - Peer Peer Peer Protection - to - Peer Protection - IP Multicast Multicast replication at hub Multicast replication at hub Multicast replication in I P WAN network Page 10 of 220 © 2018 Cisco Systems, Inc. Cisco Confidential/Proprietary GETVPN Design and Implementation Guide

11 1.5 Further Reading technology and discusses key aspects of the While this document provides an overview of the GETVPN depth technology primer. For further details on the - technology, it should not be considered an in GETVPN technology, ref er to following documentation: GETVPN Documentation on  http://www.cisco.com http://www.cisco.com/go/getvpn  Feature Documentation GETVPN xml/ios/sec_conn_getvpn/configuration/15 - IOS platforms: https://www.cisco.com/c/en/us/td/docs/ios - mt/sec - - book.html mt - 15 get - vpn - xml/ios/sec_conn_getvpn/configuration/xe https://www.cisco.com/c/en/us/td/docs/ios XE platforms: - IOS - - vpn book.html 3s - xe - - - get - 3s/sec of Page 11 220 © 2018 Cisco Systems, Inc. Cisco Confidential/Proprietary GETVPN Design and Implementation Guide

12 Config GETVPN 2. uration This chapter describes the basic configuration and verification of the following components: GETVPN ● for GDOI and G - Key servers (KSs) and group members (GMs) IKEv2 ● Pre shared key (PSK) and public key infrastructure (PKI) - ● Unicast and multicast rekey ● Cooperative (COOP) KSs ● IPsec Inline Tagging for Cisco TrustSec ● GETVPN GDOI Bypass ● GETVPN CRL Checking ● GETVPN Routing Awareness Chapter 3, ―System Design‖ and Chapter 4, ―Enterprise Deployment,‖ provide detailed descriptions of GET - VPN design and deployment , respectively. 2.1 Implementing GETVPN GETVPN level - a high 4 illustrates system configuration topology. Figure System Configuration Topology Figure 4. 1 - S K K 2 - S a y P r i m ( r K S ) S ) K y c r a d n o ( S e 6 6 1 / 2 . 5 . 8 1 2 7 1 1 / 2 . 4 . 6 1 . 2 7 1 . L S / I P P M N e t k r w o 1 2 . 1 . 9 . 2 7 1 6 1 / 0 6 1 / 2 . 2 . 2 . 2 7 1 B M - A G M - G 1 . 1 . 8 1 . 0 1 1 . 0 / . 9 2 . 1 6 8 . 1 1 0 / 1 6 . 0 1 0 . 0 0 1 . A s o s t H H o t B 2 onnects VPN sites network. The IP VPN core interc GETVPN is used to setup the The topology in Figure B and A as shown in the figure. The CE/CPE routers (GMs ) on each VPN site are grouped into a GDOI of Page 12 220 © 2018 Cisco Systems, Inc. Cisco Confidential/Proprietary GETVPN Design and Implementation Guide

13 - group. Therefore, all KSs and GMs are part of the same VPN. KS 2 is the - 1 is the primary KS and KS secondary KS. 2.2 KS Configuration assumed that all connectivity (default routes, routing protocols (RPs), and so on) are set up before the It is KS is configured. 2.2.1 Configuring IKE Internet Key Exchange (IKE) comprises the following ● nt Protocol (ISAKMP) policy Configuring Internet Security Association and Key Manageme ● Configuring the authentication method 2.2.1.1 Configuring ISAKMP Policy The IKE Phase 1 (ISAKMP policy) configuration follows: crypto isakmp policy 10 encr aes 128 hash sha256 14 group 2.2.1.2 Configuring Authentication uthentication can be done using one of the two methods A ● Using PSKs ● Using PKI 2.2.1.2.1 Authentication Using PSKs the shared‖ means the parties must agree on a shared secret key that must then be predefined in - ―Pre encryption devices. The keys are configure d as follows: share - crypto isakmp policy 10 authentication pre crypto isakmp key Cisco address 172.18.5.2 crypto isakmp key Cisco address 1 72.19.1.2 crypto isakmp key Cisco address 1 72.20.2.2 2.2.1.2.2 Authentication Using PKI based deployme - nts under the ISAKMP policy, the correct authentication method must be set and a In PKI certificate from a certificate authority (CA) must be obtained. These steps, which follow, must be repeated for all devices (GMs and KSs) in the network. ation in IKE Configuring Authentic sig. This can be done as follows: - In IKE Phase 1, authentication must be configured to rsa crypto isakmp policy 10 sig - authentication rsa of Page 13 220 © 2018 Cisco Systems, Inc. Cisco Confidential/Proprietary GETVPN Design and Implementation Guide

14 sig is the default authentication method for an ISAKMP policy. This command does not appear - rsa Note: onfiguration in the c of 220 14 Page © 2018 Cisco Systems, Inc. Cisco Confidential/Proprietary GETVPN Design and Implementation Guide

15 Generating RSA Keys Unique RSA keys must be generated on all KSs and GMs as follows: 2048 modulus IDCertKey keys label KS(config)#crypto key generate rsa general - The name for the keys will be: IDCertKey 2048 % The key modulus size is bits % exportable... [OK] - bit RSA keys, keys will be non 2048 Generating Note: RSA keys used for PKI are different than the RSA keys generated and used for KS synchronization and policy generation. The KS COOP RSA keys must be the same on all KS serving a group, while KS CA RSA keys should be unique. Configuring the Router for the CA All routers (KS and GM) are configured with trust points as follows: crypto pki trustpoint GETVPN :80 172.17.1.2 enrollment url http:// subject name OU=GETVPN - check none revocation - enroll 70 auto - rsakeypair IDCertKey 2048 Authenticating to the CA Server Authenticating to the CA server is performed to receive the certificate from the CA. The configuration follows: GETVPN authenticate KS(config )#crypto pki owing attributes: Certificate has the foll Fingerprint MD5: FFD61C4E F12676BA FAADEFD4 E205EA6B 4530D929 EA0A6383 14241669 6B7063DB D765D162 Fingerprint SHA1: % Do you accept this certificate? [yes/no]: y Trustpoint CA certificate accepted. Enrolling to the CA Server Requesting a router certificate from the CA is done as follows: enroll #crypto pki KS(config) GETVPN % % Start certificate enrollment .. of Page 15 220 © 2018 Cisco Systems, Inc. Cisco Confidential/Proprietary GETVPN Design and Implementation Guide

16 % Create a challenge password. You will need to verbally provide this ficate. password to the CA Administrator in order to revoke your certi For security reasons your password will not be saved in the configuration. Please make a note of it. Password: Re - enter password: OU=GETVPN % The subject name in the certificate will include: KS % The subject name in the certificate will include: % Include the router serial number in the subject name? [yes/no]: n n % Include an IP address in the subject name? [no]: Request certificate from CA? [yes/no]: y % Certificate request sent to Certificate Authority N verbose‟ command will show the % The „show crypto ca certificate GETVP fingerprint. KS(config)# Certificate Request Fingerprint MD5: May 12 15:12:43: CRYPTO_PKI: 1F12E4B5 ABDB70F8 E0A7DB49 DD327570 Certificate Request Fingerprint SHA1: May 12 15:12:43: CRYPTO_PKI: 18186C7B 1FFDCFAA 42678D80 1633479F 415D50EB GroupMember - 1(config)# CERTRET: Certificate received from Certificate - May 12 15:12:45: %PKI - 6 Authority certificates pki KS#sh crypto Certificate Available Status: 0x6E Certificate Serial Number: General Purpose Certificate Usage: of Page 16 220 © 2018 Cisco Systems, Inc. Cisco Confidential/Proprietary GETVPN Design and Implementation Guide

17 uer: Iss cn=GET ENG ou= o=CISCO l=RTP s t=NC Subject: Name: KS hostname=KS ou=GETVPN Validity Date: 20 start date: 10:15:09 EST Apr 25 1 2 7 end date: 10:15:09 EST Apr 25 201 GETVPN Associated Trustpoints: CA Certificate Status: Available 0x1 er: Certificate Serial Numb Certificate Usage: Signature Issuer: cn=GET ou= ENG o=CISCO l=RTP st=NC Subject: cn=GET ou= ENG o=CISCO l=RTP st=NC Validity Date: 12 20 start date: 17:11:56 EST Jun 12 7 201 end date: 17:11:56 EST Jun 10 of Page 17 220 © 2018 Cisco Systems, Inc. Cisco Confidential/Proprietary GETVPN Design and Implementation Guide

18 Associated Trustpoints: GETVPN so that routers can re enroll with the CA server before - Note: It is reco mmended to configure auto - enroll enroll configuration, the network administrator will have to the expiry of the certificate. Without the auto - - manually re ire. If the KS refuses to accept expired certificates enroll all routers before the certificates exp during registration, then the GMs will suffer an outage, causing a disruption in the network Tip : A.3.1 ―Configuration‖ contains a sample IOS CA configuration. It is also possible to deploy GETVPN IOS CA and KS on the same device for small - scale deployments. 2.2.2 Configuring IPsec Parameters Transform - set and lifetime configuration for the group IPsec SA is defined as follows. hmac - - aes esp sha - crypto ipsec transform - set mygdoi - trans esp ofile gdoi crypto ipsec pr - getvpn profile - - association lifetime seconds 7200 set security - set transform set mygdoi - trans 2.2.3 Configuring GDOI Group Before starting KS configuration, generate the RSA keys to be used during rekeys. - export - keys label getvpn - general l KS( config) #crypto key generate rsa genera 2048 modulus exportable RSA keys must be generated on any KS. All KSs must share the same keys, so these keys must Note: be generated with an ―exportable‖ tag. The keys are then imported on the remaining KSs. These keys do not need to be imported on the GMs. 2.2.3.1 Configuring Unicast Rekeys 2.2.3.1.1 Configuration using Unicast Transport Mechanism The following configuration enables the KS in a router. Each group defined in the KS has an identity that is ithin the group. Here, the identity is set to 1234 for the group ̳getvpn‘. The KS also shared among the GMs w list 199 to be distributed to GMs upon registration. - defines policies using access its Further rekeys are sent through the unicast transport mechanism with two more retransm at 10 second intervals. The KS uses this retransmit configuration to resend rekeys in case acknowledgements are not received from the GM for the rekey sent earlier. The lifetime validity - of the rekey policy is configured for 24 hours. The time replay (TBAR) value is set to based - anti five seconds. crypto gdoi group getvpn identity number 1234 ! local keyword identified this router as key server server local ! lifetime of rekey policy set to 24 hours of Page 18 220 © 2018 Cisco Systems, Inc. Cisco Confidential/Proprietary GETVPN Design and Implementation Guide

19 rekey lifetime seconds 86400 umber 2 rekey retransmit 40 n ! RSA key export - general - rekey authentication mypubkey rsa getvpn ! Rekeying through unicast transport rekey transport unicast sa ipsec 1 ! Transform - set for group members getvpn profile - - profile gdoi ! Policies defining traffic to be encrypted h address ipv4 199 matc replay set to 5 sec - ! Time based anti size 5 - replay time window ! Source address of the rekey packet 172.16.4.2 address ipv4 The GETVPN policies defined in the KS are downloaded to all GMs. 2.2.3.2 Configuring Multicast Rekeys It is as sumed that all multicast routing (Protocol Independent Multicast (PIM), sparse mode, rendezvous point, and so on) are configured and working before the multicast rekey configuration is deployed. 2.2.3.2.1 Configuration using Multicast Transport Mechanism GETVPN Multicast rekey is the default rekey method in (do not configure ―rekey transport unicast‖).The multicast group address, to which rekeys are sent, must be configured. crypto gdoi group getvpn identity number 1234 server local ! ! multicast group a ddress ! rekey address ipv4 198 rekey lifetime seconds 86400 rekey retransmit 10 number 2 of Page 19 220 © 2018 Cisco Systems, Inc. Cisco Confidential/Proprietary GETVPN Design and Implementation Guide

20 export - rekey authentication mypubkey rsa getvpn general - sa ipsec 1 profile gdoi - profile - getvpn match address ipv4 199 replay time window - size 5 The access list is def - follows: ined for any source address to access the multicast group 239.77.77.77 as access - list 198 permit ip any host 239.77.77.77 2.2.4 Configuring Access List Policies ables only GMs that The following access control list (ACL) defines policies to be pushed to GMs. This en GETVPN are configured in the 10.1.0.0/16 network address range to communicate using . The ACL GETVPN GET is mapped to the VPN configuration as shown in 2.2.3.1 Configuring Unicast Rekeys. It is also possible - l subnets in the network simply by defining a ―permit ip any any‖ entry, and to define an ACL to encrypt al adding deny statements in the ACL to deny all control plane traffic from the encryption policies. GETVPN supports both Symmetric and Asymmetric policies on the key server. mple, with symmetric policies the following can be configured on the key server: For exa Symmetric: permit ip any any Symmetric: permit ip 10.0.0.0/8 10.0.0.0/8 the key However for Asymmetric permit policies to work correctly, a reciprocal policy has to be configured on server as follows: Asymmetric: 10.0.0.0/8 any permit ip permit ip any 10.0.0.0/8 <==== reciprocal required for permit statements Asymmetric: 16.0.0/16 172. 10.0.0.0/8 permit ip permit ip 172. 16.0.0/16 10.0.0.0/8 <==== reciprocal required for pe rmit - access list 199 remark ACL policies pushed to authenticated group members access - list 199 permit ip 10.1.0.0 0.0.255.255 10.1.0.0 0.0.255.255 2.2.4.1 Changes in the behavior of the GETVPN crypto policy list policy installed on the GM under the This section discuss the differences in the behavior of the access - es following 2 conditions: list is downloaded from KS - cess When the ac 1. of Page 20 220 © 2018 Cisco Systems, Inc. Cisco Confidential/Proprietary GETVPN Design and Implementation Guide

21 list is configured locally on the GM - When the access 2. hen access 1. W - list is downloaded from KS: list policy will be installed on the GM in a centralized model. In this model, both the - oaded access Downl inbound and outbound IPsec SAs will be installed with the same source destination addresses. - For example: nfigured on the KS Consider the following topology and ACL rule co Host/Network A ------------- GM1================GM2 ------------- Host/Network B list 101 permit ip host A host B - access The ACL will install the following policy on GM1 and GM2: Outbound policy: Encrypt traffic from host A to host B policy: Decrypt traffic from host A to host B Inbound Based on the above policy, traffic from A to B will be encrypted on GM1 and decrypted on GM2. However, traffic from B to A will go in clear. In order to secure traffic from B to A, a reciprocal ACL rule needs to be configured on the KS: - access list 101 permit ip host B host A The reciprocal ACL will install the following policy on GM1 and GM2: Outbound policy: Encrypt traffic from host B to host A Inbound policy: Decrypt traffic from host B to host A 2. Behavio r when access - list policy is locally configured on the GM: Locally configured access - site model. In this model, the - to - list policy will be installed on the GM in a site destination address as the ACL rule, while the outbound IPsec SA will be installed with the same source - destination addresses. Please note that only - inbound IPsec SA will be installed with the inverted source deny access - list entries can be configured locally on GMs. For example: Consider the following topology and ACL rule configured on t he locally GM1 ------------- Host/Network C Host/Network D ------------- GM1================GM2 list 101 deny ip host C host D - access The ACL will install the following policy on GM1: Outbound policy: Do NOT encrypt traffic from host C to host D Inbound policy : Do NOT decrypt traffic from host D to host C Based on the above policy, traffic from C to D will be sent in clear, while traffic from D to C will bypass decryption. of Page 21 220 © 2018 Cisco Systems, Inc. Cisco Confidential/Proprietary GETVPN Design and Implementation Guide

22 2.3 GM Configuration ) is set up initially before GM configuration It is assumed that all connectivity (default routes, RPs, and so on takes place 2.3.1 Configuring IKE IPsec transform - sets and profile configurations are not required on GMs. These parameters are pushed e required to enable a GM and down by the KS as part of GDOI registration. Only ISAKMP configurations ar KS to authenticate each other. crypto isakmp policy 10 128 encr aes lifetime 1200 share - authentication pre 14 group 172.16.4.2 crypto isakmp key Cisco address crypto isakmp key Cisco address 172.18.5.2 cation method, PSKs are needed in each GM only to authenticate the KS. Defined For the PSK authenti PSKs are not required to authenticate other GMs. PKI configuration is the same as in the KS. See 2.2.1.2.2 Authentication Using PKI for more information about PKI configuration. 2.3.2 Configuring the GDOI Group A GM is configured using the same group identity defined on the KS and the address of the KS. crypto gdoi group getvpn identity number 1234 ! Registration with preferred key server server address ipv4 10.1.1.1 ! If prefe rred KS not reachable, register with alternate KS in the group server address ipv4 10.1.1.5 2.3.3 Configuring Crypto Map The crypto map has a new type, gdoi, and is tied to GDOI group created in the preceding section. map 10 gdoi - crypto map getvpn up getvpn set gro GETVPN 2.3.4 Enabling Applying crypto map to the WAN interface enables GDOI. interface Ethernet0/0 description WAN interface to MPLS PE of Page 22 220 © 2018 Cisco Systems, Inc. Cisco Confidential/Proprietary GETVPN Design and Implementation Guide

23 0.0 255.255. 172.19.1.2 ip address ! crypto map enabled on WAN interface Note: Apart from E thernet interfaces, GDOI/GKM crypto maps are supported on map - crypto map getvpn 000 - ) and port CSCvh50336 – PPP interfaces (except ASR1 - tunnel interfaces, LISP interfaces, Virtual XE platforms. - nnel interfaces on IOS cha The - ip tcp adjust command is used to limit maximum segment size for TCP sessions, to avoid mss sec overhead. It is applied to the LAN interface of the p maximum transmission unit (MTU) issues causes by I GM as follows: in terface Ethernet0/1 description LAN interface of GM ip tcp adjust - mss 1360 2.4 COOP KS Configuration The preceding configuration is sufficient for a standalone KS in an enterprise network. This section describes the configuration of a COOP KS. Before depl oying COOP KS configurations, consider the following: ● Generate RSA keys in the primary KS (as required for rekeys) and export both private and public keys to all the COOP KSs. This is required in case the primary KS goes down; the rekeys sent by the newly elected primary KS will still be properly verified by the GM. ● - Election between the KSs is based on the highest priority value configured. If they are same, it is based on highest IP address. It is suggested to configure priorities for selecting the primary KS for easy setup and troubleshooting. ● Periodic ISAKMP keepalive (dead peer detection, or DPD) must be configured on the COOP KSs so that the primary KS can track the secondary KS state. ● Rekey configuration, policies, and anti - e the same for all KSs. This is not replay configurations must b done automatically in the current phase of . The user must manually track configurations. GETVPN 2.4.1 Exporting and Importing RSA Keys The procedure to export and import RSA keys follows: Primary_Key_Server(config) #crypt o key generate rsa general - keys label 2048 general modulus getvpn - export - exportable % The key modulus size is 2048 bits [OK] % Generating 2048 bit RSA keys, keys will be exportable ... Export this key to the terminal. #crypto key exp ort rsa getvpn - - general pem export Primary_Key_Server(config) terminal 3des passphrase export - % Key name: getvpn general - of Page 23 220 © 2018 Cisco Systems, Inc. Cisco Confidential/Proprietary GETVPN Design and Implementation Guide

24 Usage: General Purpose Key Key data: ----- ----- BEGIN PUBLIC KEY MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC96RhInBlxIGAq4bYd4z1FwWft cJKAoJTxfoKYwZpi5+PZ 4RQyerQSvph6X LuXnpDVlxWbjNTIoV 1CApgO/8Y0SJ 4 f BBvX4j5d9pJZJdcdIBymq3F/CEnnbJWxukHQCnN1UCgdJ87oTp4gN7THaGFM3ui2 PgfEpUH5WujPrSCQ4QIDAQAB END PUBLIC KEY ----- ----- ----- BEGIN RSA PRIVATE KEY ----- - Proc Type: 4,ENCRYPTED CBC,5DD792A00CA3675D - Info: DES - EDE3 - DEK nVKal5JqzMUeq F/1DQKDkTrNOeB5GSOqbm6/8/lz2Z6SoxbyRICSsk7tsntdvyo9 SxVh5nf4Z//gj4cKm9cM4DvC8ui66WncIvhU1+dCqQ9QK1OOZ1T3GcWMr5rCvkST +XgVtZvK/3b8CyE1vMwK5GhZ8s/BkU86fO0vdnAw3X3dlCO2kTMrttHTHh5quFJi mhgUUJJWM//Rv5k2iU3ap99FyIB+52QEKiCMYE/WmjYp8+BLcA1qLJhqTs76P/oc MWUqmRFJyTnveuh0tL57ZQXzL8tCmSh1B59TzfFftwlcWtrihZEzP4x NlM2XaZqu Ek3dX/VECRA5X0nc9ZOmaYJUyAY6Xy3ZfHlqCd8h1wQ+AxpuOqNUYwR/54r6v25k kl1aK7NZ3mh075qjdsEtXNWb+9I9RrvttNkTcbfeyZifv8ZP1YN5OcX1w1Z4E17P hxo/EFs1AwNgoY0kmgnfNi6g1f9duqykLnLtD6NONrfQQAqTLe59FXKMo9oXG3TE KJ37CayzWeIAKekxJX4YCX7CsT2njbM2WSoHTX90vB1sm0UajATpltil2WD KpAcD 3c4Lyv8oy0A6FNHJhqZJeFW3w+A0OiHeggKL5Aytoyu41I3zozvGGvhDoyjPfXmu cxaK2FywKuzz5KYrqvUGwGIAoMR8tn4pwQs7CM+MlrVMOOM7ghLmnlEziLSEis36 b94kIPs70heSclECWJrnOCP/NRJ84p4xvtwEPDA68bzlyQOgQ5mrLLwvbIR1CGgm +JyTws+j9TaDzaWSbhnt2lqtTxmkRAbRGGpjzAykONulwSXk0BZ8Q== l END RSA PRIVATE KEY ----- ----- and Import this key using cut - - paste to other KSs in the GETVPN network. The ―exportable‖ option supports this procedure for other KSs deployed later. # COOP_Key_Server(conf ig) general pem - export - crypto key import rsa getvpn exportable terminal passphrase % Enter PEM formatted public General Purpose key or certificate. - % End with a blank line or "quit" on a line by itself. pose key. formatted encrypted private General Pur - % Enter PEM of Page 24 220 © 2018 Cisco Systems, Inc. Cisco Confidential/Proprietary GETVPN Design and Implementation Guide

25 % End with "quit" on a line by itself. Trivial File In the preceding example, the terminal was used to copy RSA keys from one KS to another. A Transfer Protocol (TFTP) server can also be used to export and import keys. ! To Export the key ! o key export rsa

26 ! crypto gdoi group getvpn server local ! enabling cooperative key server function redundancy ! priority decides the role of this key server local prior ity 75 ! All other key servers must be configured 72.16.4.2 peer address ipv4 1 220 of Page 26 © 2018 Cisco Systems, Inc. Cisco Confidential/Proprietary GETVPN Design and Implementation Guide

27 2.4.2 Adding a New Cooperative Key Server The following paragraph describes the method to follow in order to add a new cooperative key server into an existing key server coope rative group. To minimize disruptions to the existing cooperative key server network, a new cooperative key server should n until its ip address is known to all the existing key servers. The introduction is carried out by ot be included adding the new ip ad dress to the peer list of the existing key servers. It is recommended that the process of the configuration changes should start with Secondary key servers first before the final change is made in the Primary. For example: Consider a cooperative KS networ k with KS1 as p rimary and KS2 as secondary KS. Follow these steps to add a new KS (KS3) to the cooperative KS network: a m i r p ( S K 1 ) y r c K y r a d n o ) e s ( 2 S 7 . . 7 1 . 2 1 : P I 1 1 2 1 P : 1 7 I . 1 8 . 1 . S P I / M L P r ) K ( s y 3 a d n S o c e 1 : P I 1 1 . . 9 1 . 2 7 - Verify the reachability of KS3 from KS1 and KS2. KS3 Add the ip address of . KS2 to - - S3 to KS1. Add the ip address of K - 2.5 G IKEv2 Configuration It is assu med that all connectivity (default routes, routing protocols (RPs) are already set up. All s well. In the subsequent sections IKEv2 a - GDOI constructs discussed in the previous sections apply to G Note that GKM is the - o enable G IKEv2 on GM and KS are described. the specific c onfigurations needed t IKEv2 constructs. generalized name for the technology to cover both GDOI and G - Figure 5. IKEv2 Protocol - GETVPN Architecture through G As shown in the figure, there are three s teps for GM‘s to download group security policy and establish secure connectivity between the other GMs in the group. — Initial GM Registration Request 1. A GM initiates a registration request to the KS, sending preferred Hellman public number (in initiator‘s KE phase 1 - d), Diffie cryptographic algorithms (in SAi payloa payload) and nonce (random number used to guarantee liveness in Initiator‘s Nonce payload). This message is the same as the IKE_SA_INIT request message defined in the IKEv2 RFC. Page 27 of 220 © 2018 Cisco Systems, Inc. Cisco Confidential/Proprietary GETVPN Design and Implementation Guide

28 2. Group Secured Comm unication — The GM‘s do not directly establish pair - wise IPsec tunnels with one another, but use the group IPsec policy and keys to secure communication between all GM‘s in a particular group. - 3. KS Rekey — The KS distributes new group keys to group members as ne eded using the G IKEv2 group - maintenance channel via unicast or multicast communication. Rekey is optional in G IKEv2. IKEv2 allows GETVPN to do the following: - G Inherit the implicit advantages of IKEv2 & the IOS IKEv2 implementation 1. 2. Keep the underlying t echnology up - to - date for future development 3. Provide a complete IKEv2 package across Cisco‘s VPN security offerings 1 2. 5 . GDOI to GKM Configuration Syntax Changes - . G or the technology going forward Group Key Management or GKM is a generalized name or acronym f referring to gkm IKEv2 does not include the Domain of Interpretation, therefore, a generic abbreviation - Group Key Management is used for a group that can use either GDOI or G IKEv2 protocols for registration 15.5(1)S and Cisco IOS Release Cisco IOS introduced in The gkm configuration syntax was and rekey. and were wherein both commands crypto gdoi , crypto gkm available. However, the Release 15.5(1)T and GDOI keyword be en deprecated as of Cisco IOS Release 15.5( 3)S or Cisco IOS Release 15.5( 3)M has gkm ced by the which supports both . IKEv2 - GDOI & G keyword repla The GKM version in Cisco IOS Release 15.5(1)S and Cisco IOS Release 15.5(1)T is as follows:  Key Server: 1.0.13  Group Member: 1.0.12 & IP - The difference in KS & GM versions is due to the GDOI Rekey ACK D3P features only existing on the KS in the first release. . eatures and Restrictions 2. 5 2 G - IKEv2 Supported F the for Configuration Guide GETVPN Refer to IKEv2 supported features and Restrictions. - list of G . 5 2. 2. 1 IKEv2 Profile Configuration Both KS & GM must specify an IKEv2 profile. The IKEv2 profile is used for initiating group member and ey server registrations & reregistrations. Either Pre Shared Key (PSK) or Public Key processing k IKEv2. Infrastructure (PKI) can be used. The IKEv2 Smart Defaults works seamlessly with G - of Page 28 220 © 2018 Cisco Systems, Inc. Cisco Confidential/Proprietary GETVPN Design and Implementation Guide

29 To configure IKEv2 profie, - gikev2 crypto ikev2 profile gkm l 10.0.0.1 match address loca match identity remote address 10.0.0.5 authentication local pre - share key - share key authentication remote pre keyring local kyr_aaa crypto ipsec profile gkm - ipsec - profile set TEK - set transfor set ikev2 - profile gkm - gikev2 - 2. 5 . 2 .2 G IKEv2 Key Server Configuration GDOI & G IKEv2 are enabled or disabled independently in each group. This configuration does the - following:  Specifies which type(s) of registration can be serviced by the KS KS  Specifies which type(s) of rekey will be sent by the - enabled and G - is GDOI t The defaul Note: IKEv2 disabled. crypto gkm group gkm grp1 - server local gdoi gikev2 gkm - gikev2 2. 5.2.3 G - IKEv2 Group Member Configuration Only o ne protocol, either GDOI or G - IKEv2, can be specified in each group on a GM . grp2 - crypto gkm group gkm gkm gikev2 client protocol - gikev2 This configuration does the following:  Specifies which registration protocol will be used by the GM  Specifies which rekey protocol will be expected by th e GM IKEv2 co nfigurations Refer Appendix A.4 for complete G - . gdoi ration Note: The default client protocol is ppendix () for detailed configu and not g - ikev2 . Refer to the a example. 5 2. - IKEv2 Migration 3 . GDOI to G - G Over a period of time, you may want to upgrade and migrate your key servers and group members to IKEv2 for an entire GETVPN group requires - IKEv2 which is recommended. Migration from GDOI to G careful planning. You cannot migrate all your group members at the same time. The migration entails mmunicate using the same traffic IKEv2 group members to co - allowing GDOI group members and G of Page 29 220 © 2018 Cisco Systems, Inc. Cisco Confidential/Proprietary GETVPN Design and Implementation Guide

30 — - IKEv2. A GDOI to G - IKEv2 encryption key (TEK) while using different control plane protocols GDOI and G migration sequence includes the following:  — The new Cisco IOS software image containing the GETVPN G - IKEv2 Backward compatibility feature must support existing GDOI features and must be consistent with for earlier releases of GDOI features for Cisco IOS software.  Service upgrade — The recommended sequence for changing the Cisco IOS software image is secondary key server, prima ry key server, and group member.  Service downgrade — The recommended sequence for changing the Cisco IOS software image is group member, secondary key server, and primary key server. Detailed migration procedures with examples are illustrated in the G - IKEv2 configuration guide . 2.6 Suite B Support for GETVPN - The National Security Agency (NSA) along with the Nati onal Institute of Standards and Technology (NIST) has proposed a set of cryptographic algorithms named Suite - B as a standardized & interoperable base for cryptographic operations. These cryptographic algorithms include: GMAC bit keys, - with 128 and 256 - AES or GCM - AES  Elliptic - Curve Digital Signature Algorithm (ECDSA) for digital signatures,  - Elliptic - Curve Diffie Hellman (ECDH) for key agreement, and   Secure Hash Algorithm 2 (SHA - 256 and SHA - 384) for message digest / integrity. The GET VPN Support with Suite B feature allows these cryptographic algorithms to be used with GDOI and GMAC. - GCM/AES - 2 and AEC - SHA - - in various ways, including the use of SHA 2/HMAC GETVPN B implementation, configuration Configuration Guide for details on GETVPN and Refer to - Suite GETVPN verification with examples. of Page 30 220 © 2018 Cisco Systems, Inc. Cisco Confidential/Proprietary GETVPN Design and Implementation Guide

31 System Design GETVPN 3. GETVPN starts with selection of supported platforms and Cisco IOS releases for To design a network, one the group members (GMs) and one or more key servers (KSs). KS selection depends largely on scalability requirements, while GM selection depends largely on performance. After selecting GETVPN the right platforms and software for a network, choosing the right policies for KSs, cooperative (COOP) KSs, and GMs is vital for successful deployment and operation. The maximum n consideration. This chapter GETVPN network is another important desig transmission unit (MTU) in a addresses these design considerations in detail. 3.1 Platform Support Table 2 lists the most common platforms in the Cisco enterprise portfolio having encryption capability and modules targeting support. GETVPN GETVPN Table 2. Currently Suppo rted Platforms KS Product Line GM 841M Not recommended Yes Not recommended Yes 87x 880/890 Not recommended Yes Yes Not recommended ISRv 1100 Yes Not recommended 1 Yes Yes 1900 ( for 1941 ) 2 Yes Yes 2900 2 /E Yes Yes 3900 ISR 4200 Yes Not recomme nded Yes ISR 4300 Yes (only 4351) Yes Yes ISR 4400 Yes Yes ASR1000 Yes Yes ASR1000 - X HX - ASR1000 Yes Yes Yes Yes CSR1000v 3.2 IOS Software Releases Please contact your Cisco representative for the most updated IOS release recommendations. of Page 31 220 © 2018 Cisco Systems, Inc. Cisco Confidential/Proprietary GETVPN Design and Implementation Guide

32 3.3 KS S election KS selection depends largely on the required network scalability (the number of GMs supported in a group). The limiting factors in KS scalability are the registration rate (how quickly GMs can register with a KS) and the ability of the KS to handl e rekeys to maintain GM synchronization. By far, the registration rate is the single most important factor in the KS selection process. The goal of KS server selection for a specific network is to keep registration time low so that, in case of KS rekey fai lure, GMs can reregister within a reasonable time and continue to forward data without disruption. on cisco.com for Table 2 shows the supported platforms for Key Server, r efer to GETVPN CCO document s epresentative for more detailed KS performance and . Please contact your Cisco r the KS scalability numbers scalability data. The 8000 GM Scale Improvement feature supports optimization of the Cooperative Protocol (COOP) er scale announcement messages by increasing the number of Group Members (GM) to 8000 from the earli of 4000. This feature is available from Cisco IOS Release 15.5(1)T and Cisco IOS 15.5(1)S . To use this feature to increase the GM scale from 4000 to 8000, use the protocol version optimize command under the . gdoi/gkm group on the Key Server r . document for more details on the procedure 8K GM Scale Improvement the to Refe 3.4 GM Selectio n A GM should be selected based on the required throughput or packet forwarding rate. If the traffic mix primarily comprises small packets (for example, as in VoIP), the packets/second performance is more important. If the traffic mix primarily comprises l arge packets for example, as in file transfers), throughput performance is more important. T his is because the packet/second forwarding performance is processor bound, while throughput performance is typically crypto engine bound. 3.4.1 GM Performance erformance characterization is based on the following parameters: GM p ● QoS is not enabled ● Hardware crypto ● Identical configuration for all platforms Please contact your Cisco representative for a detailed GM performance data. 3.4.2 Number of Security Association s (e.g. 800 series) Some platforms support only a limited number of security associations (SAs) . In GETVPN , SAs are created before existing IPsec SAs IPsec IOS - based IPsec solutions, new like almost all other ryption module) selection consideration is the ability to expire. Therefore, an important platform (or enc support at least twice the number of configured IPsec SAs. GETVPN For example, if a policy results in creation of 100 SAs on the GM (50 permit entries in the encryption ACL or 300 ), the platform should be able to handle d 50 inbound SAs creates 50 outbound SA an of 220 Page 32 © 2018 Cisco Systems, Inc. Cisco Confidential/Proprietary GETVPN Design and Implementation Guide

33 more SAs. Note that many policy changes on the KS (ACL changes, for example) also result in a rekey and therefore create additional SAs. oyment Typical choice of platforms in an Enterprise depl 3 3.4. shows a typical choice of IOS platforms as GMs and KSs at the branch and data center (DC) based Figure 6 at branches depends on the connection s model on these parameters. The choice of ISR and 4000 ASR1000 type and throughput requirements, among oth er parameters. Figure 6. Typical Enterprise Choice of Platforms 3.5 KS Design Considerations 3.5.1 ISAKMP The KS should be configured in AES mode for encryption using 128 bit (or better) keys because AES mode provides more robust security with reduced computation o verhead. The lifetime of ISAKMP sessions on the KS is recommended to be the default lifetime of 24 hours. The KSs need the IKE session active to transmit COOP messages between themselves. This is a persistent database synchronization process, so the IKE se ssion is always required. There is no point in tearing down the IKE session because it is immediately restored. To configure: crypto isakmp policy 10 encryption aes hash sha256 lifetime 86400 To verify the preceding configuration, use ―show crypto isak mp policy‖. ISAKMP periodic dead peer detection (DPD), also called keepalives, must be configured on all KSs (only) so the primary COOP server can keep track of the state of the secondary KSs. crypto isakmp keepalive 15 periodic 3.5.2 IPsec ommended for the Traffic Encryption Key. Since AES mode provides more robust security AES mode is rec with minimal computation overhead. To configure: - sha - crypto ipsec transform hmac aes esp set AES_SHA esp - - ! crypto ipsec profile gdoi1 association lifetime se - set security conds 7200 - set transform set AES_SHA ! of Page 33 220 © 2018 Cisco Systems, Inc. Cisco Confidential/Proprietary GETVPN Design and Implementation Guide

34 crypto gdoi group dgvpn1 identity number 61440 server local rekey lifetime seconds 86400 rekey retransmit 40 number 3 rekey authentication mypubkey rsa getkey rekey transport unicast sa ipsec 1 prof ile gdoi1 match address ipv4 160 no replay address ipv4 172.16.4.2 To verify the configuration, use show crypto gdoi ks policy. that all traffic encryption key (TEK) , ensure GM platforms used in the deployment Before using S uite B for platform . For more information regarding e uit S support B platform support for Suite B, see: - ike - technote - https://www.cisco.com/c/en/us/support/doc s/security - vpn/ipsec protocols/116055 negotiation - - - crypto.html ios 3.5.3 Traffic Encryption Key Lifetime The traffic encryption key (TEK) lifetime should be no less than the default 3600 seconds. The TEK lifetime should never be set below 900 seconds in real deployments because a short TEK lifetime creates more key rollovers that must be synchronized among all GMs. If the KS has insufficient time to complete key system operates in an distribution before prepositioning the security association with the next TEK, the unstable state. The longer lifetime improves network stability and minimizes network change. A TEK lifetime value to use. of two hours (7200 seconds) is the recommended If policies change frequently on the KS (for example, during earl y deployment stages), the TEK lifetime can ; however, setting the TEK lifetime too low leads to be lowered to minimize the number of active SAs excessive key generation and key overlap. Setting the TEK lifetime to 900 seconds is commonly done in a ng where clearing the entire network is feasible. lab setti To change the lifetime, use the following configuration: crypto ipsec profile gdoi1 set security association lifetime seconds 7200 - To verify the configuration, use ―show crypto gdoi ks policy‖. ime at which the KS sends rekeys depends on the number of GMs, retransmission The actual t Note: values, and a maximum of 10% or 90 sec head start value. The following formula can calculate the actual rekey time: smission time) + (5 x Number of GMs/50)] [Max(10% of lifetime or 90 sec) + (required retran - Lifetime of Page 34 220 © 2018 Cisco Systems, Inc. Cisco Confidential/Proprietary GETVPN Design and Implementation Guide

35 For example, for 1000 GMs, a configured TEK lifetime of 7200 seconds and two retransmissions (60 seconds apart), the KS sends rekeys every 6260 seconds: (additional time to cover 1000 GMs)] [720 (10% lifetime) + 120 (60x2 retransmissions) + 100 – 7200 The example provided leads to a TEK lifetime overlap of 940 seconds. The new TEK is pre - positioned 940 seconds prior to the expiration of the previous TEK. While the new TEK is distributed prior to its use, the GM‘s w ill always encrypt with the TEK with the least remaining TEK lifetime. The GM‘s will start encrypting with the new TEK when 30 seconds reaming in the previous TEK‘s lifetime. 3.5.4 Long SA The GET tr enhances VPN Resiliency features oubleshooting capability VPN in GET and operation stability networks so that traffic disruption is prevented or minimized when errors occur. One of the resiliency feature g SA Lifetime. is Lon VPN ing By choosing a longer TEK and KEK lifetime, the KS rekey frequency is reduced, thus, improv GET operation stability by: Lowering the chance of rekey failures  KS split/merge - Lowering the chance of rekey happening during COOP   Lowering the KS CPU usage due to rekey To configure Long SA Lifetime for TEK: enable configure terminal - p sec profile gdoi crypto ip association lifetime days 15 - set security To configure Long SA Lifetime for KEK: enable configure terminal crypto gdoi group GET identity number 3333 server local rekey lifetime days 20 Long SA Refer to the document f or more information. 3.5. ACL in Traffic Encryption Policy 5 (ACL) for encryption policy should include the subnets which The permit entries in the access control list must be encrypted. The maximum number of lines in a traffic ACL is 100. Note that each permit statement in the KS ACL results in an SA on the GM, so the number of permit entries should be limited to minimize the SA database (SADB) on the GM. As mentioned, it is possible to add a single ―permit ip any any‖ entry in the ACL to encrypt all example, traffic. However, explicit deny entries should be configured in the ACL to exclude control traffic (for routing protocols) from encryption. The network designer must determine what traffic requires encryption. The following protocols, which are commonly denied in encryption policy, are provided for reference. of Page 35 220 © 2018 Cisco Systems, Inc. Cisco Confidential/Proprietary GETVPN Design and Implementation Guide

36 ip access - list extended encryption_list deny es p any any tcp any any eq tacacs deny tcp any eq tacacs any deny deny tcp any any eq ssh deny tcp any eq ssh any CE adjacency deny tcp any any eq bgp ; when GM‟s use BGP for PE - - tcp any eq bgp any ; when GM‟s use BGP for PE deny CE adjacency ospf a ny any deny ; when GM‟s use OSPF for PE - CE adjacency ; when GM‟s use EIGRP for PE - deny eigrp any any CE adjacency deny pim any 224.0.0.0 0.0.0.255 !deny udp any any eq ntp ; optional ; optional !deny udp any any eq dns !deny udp any any eq snmp ; optional !d ; optional udp any any eq syslog eny ; optional !deny udp any any eq 1645 !deny ; optional udp any any eq 1646 udp any any eq 1812 !deny ; optional !deny udp any any eq 1813 ; optional !deny tcp any eq 443 any ; optional !deny tcp any any eq 443 ; optional deny udp any eq isakmp any eq isakmp udp any any eq 848 deny permit ip any any Note: ― entry during deployment. If ‖ permit ip any any One should exercise extreme caution when using this entry accidentally precedes deny entries for control and management traffic, and the ACL is downloaded to GMs, this can break control/management traffic by encrypting updates. A recommended best practice is to insure that any bootstrap management and control protocols are denied encryption on the local GM during early deployment p hases. A global deny policy may be constructed for all GM‘s and deployed from the KS to insure that all management and control bootstrap protocols are never encrypted . s do not need explicit deny Note: ISR GM ACL entries for IKE/GDOI traffic. The deny entries ar e required XE for ASR GMs running IOS - XE releases prior to 3.8 or 15.3(1)S . support access - lists that have discontiguous wildcard netmasks. For SR 1000 GMs Cisco A do not Note: example, the following access list entry is not supported: - of Page 36 220 © 2018 Cisco Systems, Inc. Cisco Confidential/Proprietary GETVPN Design and Implementation Guide

37 access - list 101 permit ip 1 0.0.0.1 0.255.255.0 192.168.0.0 0.0.255.255 Please design the network such that the TEK ACL will have contiguous netmasks. For example, the above access - list entry would be modified as: 55 access - list 101 permit ip 10.0.0.1 0.255.255.255 192.168.0.0 0.0.255.2 3.5.6 CRL Checking certificates are validated , When PKI is used for authentication during the initial session establishment xisting between GM and KS. If a certificate gets revoked after the session is established, these e sessions revocation notifies KSs e VPN GET CRL Checking feature . The of that certificate are not affected by th through public key infrastructure (PKI) when a new CRL is available for a configured trustpoint. The KS creates a new Key Encryption Key (KEK) and sends a reauthentication messa ge to the group member devices, which print a syslog message, delete the current KEKs, and reregister to the KS. The GETVPN CRL Checking feature provides the following  New reauthentication configuration for GETVPN to specify a PKI trustpoint. s GETVPN when a new CRL is available for download at the PKI server. PKI notifie   GETVPN verify if new CRL matches the configured PKI trustpoint.  If the CRL matches, GETVPN KS start a reauthentication process to have all GMs reregister.  The reauthentication process wil l be similar to a GM removal. You need to configure several components prior to enabling the CRL Checking feature. These GET VPN include:  A defined PKI certificate authority (CA) so that group members and key servers are PKI clients and, oll to get certificates. therefore must enr  KSs configured to have certificate revocation list (CRL) checking enabled in PKI. needed basis.  - KSs configured to download the CRL when it is available on the CA and on a first first group member (GM) registration after This means that the KSs download the CRL following the the new CRL is available.  CRL checking disabled on the group member devices for PKI.  Internet Key Exchange (IKE) authentication set to certificates. KSs L when the first group member registration are configured to download the CR In the following example, occurs after a new CRL is available on the trustpoint CA named mycert: ip domain name cisco.com ip http server crypto pki trustpoint mycert enrollment url http://10.1.3.1:80 check crl - revocation y abcd crypto identit unix5.cisco.com - fqdn ut01 unix6.cisco.com - fqdn ut01 of Page 37 220 © 2018 Cisco Systems, Inc. Cisco Confidential/Proprietary GETVPN Design and Implementation Guide

38 group1 - group gdoi gkm crypto server local authentication identity abcd Crypto gdoi group gdoi_group1 erver local s registration periodic crl trustpoint mycert more information. Refer to CRL Checking document for 3.5. 7 Key Encryption Key Lifetime The key encryption key lifetime should be left at the default of 86400 seconds. Since the KEK is used to encrypt the control pl ane messages between the KS and GM. Changing the KEK value frequently subjects and subsequently requiring the GM misses to rekey the GM to possible - re at register more frequently than is necessary. It is recommended that the KEK lifetime should always be TEK lifetime. least double the To change the value: crypto gdoi group dgvpn1 identity number 61440 server local rekey lifetime seconds 86400 To verify the value, use show crypto gdoi ks policy. 3.5. 8 Rekey Retransmit Interval uld be configured using one of the following schemes: Rekey retransmits sho Two retransmissions at 60 second intervals or  Three retransmissions at 40 second intervals.   3 schdeduled rekeys The rekey retransmit interval should be set as shown because for groups with many GMs, can take a significant time to send unicast rekey messages. Retransmission should start it after a complete cycle of rekey messages with sufficient time for acknowledgements. in advance of TEK Larger rekey intervals and retransmissions ensure that TEKs are prepositioned well expiration, and mitigate the impact of network partitioning. The retransmission and rekey interval duration should also exceed the KS DPD, and IP convergence in the core network. To configure this value: crypto gdoi group dgvpn1 y number 61440 identit server local rekey retransmit 40 number 3 - up rekey functionality in the key server (KS) lets you to send periodic reminder The periodic reminder sync rekeys to group members (GMs) who do not respond with an acknowledgment (ACK) in the las t scheduled of Page 38 220 © 2018 Cisco Systems, Inc. Cisco Confidential/Proprietary GETVPN Design and Implementation Guide

39 rekey. This functionality in combination with the long SA lifetime functionality is effective for a KS to synchronize with GMs when they miss a scheduled rekey before the keys rollover. In a KS group ed to the rekey retransmit command when configuring the rekey configuration, a new keyword periodic is add retransmission. Each periodic rekey increments the sequence number, similar to rekey retransmissions. The GM is removed ) for which the GM does not send from the database on the KS after 3 scheduled rekeys (not retransmissions an ACK. If periodic is used, here is the configuration snippet: crypto gdoi group group1 identity number 3333 server local rekey retransmit 10 periodic To verify this value, use show crypto gdoi ks rekey. 3.5. 9 IKEv2 pro file based G - IKEv2 authorization enabled network, a Key Server (KS) authorizes a Group Member (GM) on the GM‘s identity. In a G IKEv2 - - The identities currently supported by KS are IP address, fully qualified domain name (FQDN) distinguished , name (DN) , emai l . The identity of a GM used for authorization is same as the identity used in id and key - id - feature leverages IKEv2 supported identities This G - IKEv2 Enhancement for GETVPN IKEv2 protocol. - thereby enabling IKEv2 profile orks. The GM identity is used by IKEv2 IKEv2 netw - based authorization on G and GKM on KS to authenticate the GM. IKEv2 uses its identity to bring up a session and GKM uses identity for GM registration. In case of GDOI - based networks, the authorization must be configured via the in the GDOI/GKM group. authorization command access control list configuration in authorization list, an Note: Although, GDOI and G - IKE v 2 support s - IKEv2 does not support ACL in identity configuration. Therefore ACL is not supported on G IKEv2 networks plicable for GDOI networks but is supported and ap . To configure IKEv2 profile based G - IKEv2 authorization, crypto ikev2 profile IKEv2 - PROFILE match identity remote email [email protected] [email protected] identity local email match identity remote fqdn cisco.com match identity remote address 10.10.10.1 255.255.255.255 - match identity remote key id sovm identity local remote key id sovm - identity local remote fqdn cisco.com Refer to the for more information. configuration guide of Page 39 220 © 2018 Cisco Systems, Inc. Cisco Confidential/Proprietary GETVPN Design and Implementation Guide

40 3.5. 10 TBAR not be configured. TBAR should be configured on all p latforms and counter - based anti - replay should - based anti - replay makes no Because multiple sources and destinations are using the same SA, counter sense and TBAR is the only viable method. TBAR is sufficient because the KS maintains time synchronization for all GMs. This is not global time; but is a relative time clock for that security group. No Network Time Protocol (NTP) or GPS based time synchronization is required. The KS periodically transmits time sync rekeys before traffic encrypt ion key (TEK) expiration. based anti replay is configured. To configure TBAR: - By default, counter - crypto gdoi group dgvpn1 identity number 61440 server local <..> sa ipsec 1 <..> replay time window - size 5 To verify this configuration, use ―s how crypto gdoi‖. 3.5.1 1 - D3P IP - Delivery Delay Detection Protocol IP detection 04.txt - D3P uses the system on GETVPN . IP - The IP - D3P Support implements draft - weis - delay - clock of group members to create and verify the IP D3P datagram‘s timestamp. In most cases, the system - clock is set from an external protocol, such as Network Time Protocol (NTP) – which is recommended, to synchronize the system clo cks of the sender and receiver. 3.5.1 1 .1 IP - D3P Support for Key Server A new configuration command, d3p , in the GDOI local server configuration mode allows you to enable IP - D3P on a key server. The show crypto gkm ks command displays the IP D3P parameters that are enabled - on a key server. 3.5 .1 1 .2 IP - D3P Support for Group Member Group members receive the IP - D3P parameters present in the rekey messages. Group members process size, which must be - D3P - WINDOWSIZE. The window - TYPE and D3P the new GAP payload attributes — D3P for a group mem - used in IP ber, can be overwritten by using the client d3p command in the GDOI group configuration. To ensure that all devices in a GETVPN network support GETVPN interoperability features, use the ‖ command ― show crypto gkm feature feature name . This displays the GDOI version running on each key server and group member in the network and information about whether the device supports GETVPN interoperability features, namely, D3P support on GETVPN Key Server and Internet - Draft ACK for Cisco GETVPN Key Server. feature ip - d3p crypto ow Device# sh gkm 1 GETVPN Group Name: Key Server ID Version Feature Supported of Page 40 220 © 2018 Cisco Systems, Inc. Cisco Confidential/Proprietary GETVPN Design and Implementation Guide

41 10.0.8.1 1.0.11 Yes 10.0.9.1 1.0.10 No Group Member ID Version Feature Supported 10.0.3.1 1.0.11 Yes 10.65.9.2 1.0.10 No .3 3.5.1 1 Configuration 1 Enabling IP - D3P on a Key Server .3.1 3.5.1 D3P on KS, - To configure IP GET crypto gkm group VPN <..> sa d3p window msec 5000 1 .3.2 Enabling IP D3P on a Grou p Member 3.5.1 - - D3P on GM, To configure IP GET crypto gkm group VPN <..> client d3p window sec 50 3.5.1 1 .4 GDOI Rekey Acknowledgement The Internet - Draft ACK for Cisco GETVPN Key Server feature implements the standards for rekey a acknowledgment between n on - Cisco group members and messages key server , as defined in the GDOI GROUPKEY - PUSH Acknowledgment Message draft . referred The GDOI GROUPKEY - PUSH Acknowledgment message , which is to as GDOI I - D Rekey ACK , defining by differs a for method interoperable an from the Cisco unicast rekey acknowledgment messa ge server member to send a rekey acknowledgment to any key group in a group . The GDOI I - D Rekey ACK is but checked - integrity is , message acknowledgment . not encrypted , as is the case with Cisco unicast rekey a key server sends a rekey message to group members for updating the keys and policies of a group, When it is useful for a key server to know if all group members have received the rekey message and have successfully processed, installed, and responded to the new keys and policies. To ensure that all devices in a use the GETVPN network support GETVPN interoperability features, feature feature gkm . This displays the GDOI version running on each key ‖ name command ― show crypto k and information about whether the device supports GETVPN server and group member in the networ Internet interoperability features, namely, D3P support on GETVPN Key Server and Draft ACK - for Cisco GETVPN Key Server. gdoi feature ack crypto gkm interop - Device# show - Group Name: 2 GETVPN Server ID Version Feature Supported Key 10.0.8.1 1.0.11 Yes 10.0.9.1 1.0.10 No Group Member ID Version Feature Supported 10.0.3.1 1.0.11 Yes .10 No 10.65.9.2 1.0 2 Page 41 of 20 © 2018 Cisco Systems, Inc. Cisco Confidential/Proprietary GETVPN Design and Implementation Guide

42 To enable GDOI ID - Rekey ACK on a key server, configure as below. crypto gkm group GET <..> nteroperable Rekey I For more details rekey acknowledgment interoperable <..> , refer to section on this configuration guide. Acknowledgement 2 3.5.1 Authentication Policy for GM Registration GMs can authenticate to the KS at registration time using P SKs or PKI. PSKs are easy to deploy but must be managed proactively. It is recommended to deploy a peer based PSK instead of defining a default key - (the key defined with an address of 0.0.0.0) for all the devices in the network. PSKs should be updated regu larly (every few months). Note: A PSK can be updated on a KS - GM peer basis without affecting the crypto data plane or control plane because rekeys are secured using the KEK. It is important to ensure that a GM can reregister to each ordered set of KSs using the newly assigned PSK. PKI uses its infrastructure to overcome the key management difficulties encountered when using PSKs. The PKI infrastructure acts as a certificate authority (CA) where router certificates are issued and maintained. However, using PKI dur ing IKE authentication is computationally intensive. In PKI deployments, KS capacity, design, and placement become very important. For added security, GETVPN also supports GM authorization as described in the following sections. GDOI authorization is based on ISAKMP identity sent by the GM. With PSK authentication, i f GM send s ip address DN f GM send i s or as identity only "authorization address" will be used to authorize the GM . With PKI, FQDN or hostname then "authorization identity" will be used . ize the GM to author Using an IP address as an identity will bypass authorization matching a DN or hostname and vice versa. To we ensure that only GMs with a specific DN can connect (and no GMs using another identity can connect), in the aut ― deny any ‖ . horization address ACL must specify 3.5. 1 2 .1 GM Authorization Using PSKs when using PSKs. An ACL GETVPN supports GM authorization using the IP address in the IKE identity GETVPN on group configuration matching these IP addresses can be defined and applied to the GETVPN authorize successfully and can the KS . Any GM whose IP address ( in IKE identity) match es the ACL , gets d register to the KS. Else , KS rejects the GM registration request. ! ! On KS ! crypto gdoi group getvpn server local authorization address ipv4 50 ! list 50 permit 10.1.1.10 - access .1.0 0.0.0.255 68 .1 192 list 50 permit - access of Page 42 220 © 2018 Cisco Systems, Inc. Cisco Confidential/Proprietary GETVPN Design and Implementation Guide

43 ! In cases of unsuccessful authorization, the following syslog message is generated: 1 UNAUTHORIZED_IPADDR: Group getvpn received registration from - - %GDOI unauthorized ip address: 1 1 .1.9 0. 1 2 .2 GM Authorization using PKI 3 .5. DN supports GM authorization using the GETVPN FQDN when using PKI. A crypto identity (common) or group GETVPN matching certain fields in the GM certificate (typically OU) can be defined and applied to the ration. configu Any GM whose certificate credentials match the ISAKMP identity is authorized and can register to the KS. For example, if all GM certificates are issued with OU=GETVPN, a KS can be configured to check aving OU=GETVPN. If the OU in the certificate presented by a (authorize) that all GMs present a certificate h GM is set to something else, the GM will not be authorized to register to the KS. ! On KS ! crypto isakmp identity dn ! crypto pki trustpoint GETVPN - name OU=GETVPN subject ! oup getvpn crypto gdoi gr server local authorization identity GETVPN_FILTER ! crypto identity GETVPN_FILTER dn ou=GETVPN ! On GM ! crypto isakmp identity dn ! crypto pki trustpoint GETVPN subject name OU=GETVPN - ! of Page 43 220 © 2018 Cisco Systems, Inc. Cisco Confidential/Proprietary GETVPN Design and Implementation Guide

44 If authorization is unsuccessful, the following syslog message is printed on the KS: - 1 - UNAUTHORIZED_IDENTITY: Group getvpn received registration from %GDOI unauthorized identity: 1,ou= TEST - Dist. name: hostname=GroupMember GETVPN iple GDOI groups, KS authorization. When a KS serves mult : It is a best practice to turn on Tip authorization is required to prevent a GM in one group from requesting keys and policies from another group. The ISAKMP authorization confirms the GM is allowed to request GDOI attributes from the KS while ms the GM is allowed to request GDOI attributes from a specific group the GDOI authorization confir configured in the KS. Key Server Role Change 3.5. 1 3 A new CLI command provides the user with a way to change the priorities of certain key servers and shift a o Primary while demoting the old Primary to Secondary. Prior to the introduction key server from Secondary t of this command, ―clear crypto gdoi‖ was the only way to change the key server roles. However, this is a so causes the key servers to go into more drastic command and causes existing policies to be deleted and al the election mode. WARNING: The command ―clear crypto gdoi‖ when executed on the key server, clears all the existing KS and GM‘s will remain out of sync for the dura - registrations It will not force GM‘s to re tion of the register. TEK lifetime. The command to trigger a key server role change is as below (to be executed on primary KS) crypto gdoi ks coop role KS # clear On execution of this command on a primary key server  Key server relinquishes the primary role. DOES NOT clear the key server policies.  Enters election process with other key servers.   Key server with the highest priority will become primary. If the priority values of the Key Servers have been changed prior to this, a new Primary KS will be selected . Execution of this command on a secondary key server has no effect. e new priorities as per th 1 Rekey Transport 4 3.5. Unicast and multicast are the two methods of transport for GDOI rekey services. Unicast rekey is required when the WAN infrastructure does not suppo rt multicast or when the operator wishes to have positive networks GETVPN acknowledgement of GM participation in the group. Multicast rekey is required to scale beyond the limits of a KS platform‘s unicast rekey capabilities. For supporting multicast rekey s, the WAN otherwise GM‘s will persistently reregister. , infrastructure must support multicast : The rekey messages should be sent from an IP address that is not affiliated with a physical interface on Tip the KS. Should the KS lose an interface, the routin g control plane can reconverge and provide rekey messages via an alternate interface while using the same source IP address. A loopback interface is recommended as the source of the rekey messages. 4 1 3.5. .1 Unicast Rekey rekey via unicast transpor GETVPN t is recommended for deployment since it is more reliable method. The GM responds with a rekey acknowledgement and the KS processes the of Page 44 220 © 2018 Cisco Systems, Inc. Cisco Confidential/Proprietary GETVPN Design and Implementation Guide

45 acknowledgment for each rekey it sends out. The KS will attempt to resend if no acknowledgment is cular GM. The KS will remove the GM from the KS database after 3 failed rekey received from a parti retransmits. can also be a bottleneck in scaling to a very large with limited processing capabilities KS A nt factor, another important ( 1000 or more GMs). While registration rate is one importa GETVPN GETVPN traffic the factor is rekeys. during burst It is worth noting that even for 1000+ GMs, this burst lasts only for a few seconds (10 s). Below is ond 20 sec - a comparison chart for the traffic burst during rekey for different ACL s izes. From this chart, we can see that traffic rate increases with increased ACL size. Network designer should consider allocating enough bandwidth for KS in a GETVPN network. Figure 7. Unicast Rekey Data Rate and ACL Size .2 Multicast Rekey 4 3.5. 1 GETVPN rekey tra nsport using multicast is more efficient and scalable, however, currently there is no acknowledgement for each rekey a KS sends out. The KS transmits a multicast rekey message that is rekey is a single message, rekey delivered via the multicast infrastructure built in the WAN. Because the loading is not a factor in scaling bandwidth or KS platform performance. The KS must still be scaled to handle the ̳flash‘ registration load should the multicast rekey fail to reach all GMs. The registration load can be di stributed among several KS acting as COOP servers in a specific group. Deploying multicast rekey requires a very robust underlying multicast network design to make multicast rekey reliable. The multicast rekey architecture should have a multicast control p lane infrastructure established that is distinct from the control plane that serves data plane multicast. Three viable multicast architectures serve the GDOI control plane: SSM) - PIM Source Specific Multicast (PIM 1. 2. SM) - Discovery (PIM PIM Sparse Mode with Rendezvous Point Auto of Page 45 220 © 2018 Cisco Systems, Inc. Cisco Confidential/Proprietary GETVPN Design and Implementation Guide

46 - PIM Sparse Mode with Anycast Rendezvous Point and Multicast Source Discovery Protocol (PIM 3. SM with MSDP) Deploying multicast rekey without the fix for CSCso45508 (Multicast rekey not properly Note: reassembled on GMs) is not recommended. 3.6 GM Design Considerations 3.6.1 ISAKMP The AES mode of encryption with 128 bit (or better) keys are recommended for ISKAMP policy, since it provides much more robust security with minimal computational complexity compared to 3DES while DES provides minimal security capabilities. is recommended since it is more secure and stronger than SHA - 1. or higher 256 ) ( For data integrity, SHA - To configure: crypto isakmp policy 10 encr aes hash sha256 3.6.2 ISAKMP Policy Lifetime While all the ISAKMP policy parameter s must match on GM and the KS, the IKE lifetime values should be set different on both devices. IKE lifetime should not be more than 30 minutes and no less than 15 minutes. the KS, the GM will The recommended lifetime is 20 minutes or 1200 seconds. Once the GM registers with session is no longer needed to maintain use the downloaded KEK to decrypt rekey messages and the IKE the GM membership in the group. Theoretically, the GM will never need to reregister as long as rekey session is unnecessary. he IKE messages are received. Retaining t To configure: crypto isakmp policy 10 lifetime 1200 3.6.3 Local Deny Policy In addition to the traffic policy configured at the KS, local policies can also be configured at the GM and added to the crypto map. This can be he lpful if additional control or management traffic must be excluded from the encryption policy at that specific GM. Defining local policies on the GM, reduces the size of the policy pushed from the KS. Cisco recommends that the local deny policy be used for policy exceptions that are applicable only to a specific group member or for policy exceptions that are asymmetric. The global policy should be used for symmetric policy statements. If an asymmetric deny policy is applicable to every group member in the g roup, then it may be configured in the KS‘s global policy ACL. Consider the scenario in which most GMs use EIGRP as the routing protocol; a ̳deny ip eigrp any any‘ PF, the policy could be defined at the KS to be pushed down to all GMs. However, if a few GMs use OS routing control plane at these GMs would fail to maintain an adjacency because OSPF packets would be encrypted by the GM and dropped by the adjacent routing device such as a PE (typically, PE does not of Page 46 220 © 2018 Cisco Systems, Inc. Cisco Confidential/Proprietary GETVPN Design and Implementation Guide

47 ets from getting encrypted, a local ACL policy can be participate in encryption).To prevent OSPF pack created at the GM, as shown below. This policy will only affect the GM on which it is defined. The crypto policy applied at the GM represents a concatenation of the KS policy with the GM policy. The ord er of operations is such that the locally defined GM policy is checked first, followed by the KS downloaded policy: 1. GM local deny policies 2. KS downloaded deny policies 3. KS downloaded permit policies ! encrypt list extended no - - ACL - ip access ospf any any deny ! crypto map dgvpn 10 gdoi set group dgvpn - encrypt match address no ACL - ! GM1#sh cry gdoi gm acl Group Name: dgvpn : ACL Downloaded From KS 172.16.4.2 list - access deny eigrp any any access deny udp any any port = 500 list - = 848 deny udp any any port list - access access permit ip any any list - ACL Configured Locally: Map Name: dgvpn list no - - - encrypt access ACL deny ospf any any Note: Only deny statements can be added locally at the GM. Permit statements are not supported in the locally configured policies. In case of a conflict, local policy overrides the policy downloaded from the KS 3.6.3.1 Difference in handling local deny policy between IOS and IOS XE based GMs Unlike an , the GM IOS IOS XE does not reverse the source and destination IP addresses of an inbound GM p GDOI ACL. As a result we will need an additional entry in the local acket before checking for a match in the deny ACL on the IOS XE GM that matches the inbound packet‘s source and destination ip address. Following is an illustration of the difference in be havio r: Consider the following local deny ACE: ― deny ip network - A network - B ‖ Following table shows the difference in behavior of IOS and IOS XE GMs for the above ACE. GM IOS IOS XE - - GM Yes Yes Send A to B in clear of Page 47 220 © 2018 Cisco Systems, Inc. Cisco Confidential/Proprietary GETVPN Design and Implementation Guide

48 No Yes to A in clear Accept B No Send B to A in clear No Accept A to B in clear No Yes Consistent behavior between the 2 platforms can be achieved in either one of the following ways: GM from n A as follows Configure an extra deny entry in the IOS XE - etwork - B to network - A‖ - - B network ―deny ip network OR . This Configure the following command on the IOS XE GM - - both‖ ―platform ipsec gdoi accept Closed Encryption Mode - 3.6.4 ACL for Fail A group member may operate in one of two modes prior to successfully registering. A group member‘s open prior to registration. In this mode, the GM will allow all traffic to - default mode is fail be forwarded regardless of the key server‘s crypto policy because the GM is not aware of the group‘s securit y policy. closed mode. In this mode, traffic that matches the Once a group member registers, it operates in a fail - downloaded policy must be encrypted or decrypted with the appropriate keys, or dropped if no keys exist, e policy may be text. - while traffic that does not match th forwarded in clear closed state both before and after registration. The Many customers require the GM to operate in a fail - feature allows the operator to define a local crypto policy ACL on the GM that places the GM in fail - closed mod e all the times. If the GM has never registered or has its policy cleared using the ̳clear crypto gdoi‘ command, it  will operate in a fail - closed mode. If the GM successfully registers and receives rekeys, it will encrypt and decrypt the appropriate  traffi c according to the policy. Likewise, it will forward traffic that does not match the policy.  If the GM does not receive a rekey and does not successfully re - register, it will drop traffic that matches the policy while continuing to forward traffic in clea text that does not match the policy. - r closed mode following a registration of any group configured on the - The GM always operates in fail GM. event such Fail - close means that no clear traffic will leak out of a router interface after a router reboot or an open means as ―clear crypto gdoi‖; in this case the GM has not contacted the KS to download policies. Fail - the GM can forward any traffic in cleartext until the downloaded crypto policy is applied following registration. A GM boots in Fail open mode and re mains in this mode until the GM successfully registers - to a KS. Close increases the security of GETVPN and the group member by enforcing that: - Fail  Prior to registration or during registration, group member will drop any packets that arrive in the clear. Failure in any step during the registration process should also cause the group member to drop any  packets in the clear. of Page 48 220 © 2018 Cisco Systems, Inc. Cisco Confidential/Proprietary GETVPN Design and Implementation Guide

49 - Close actions on the group member are relevant only for first time registration of the group member The Fail d using the ―clear crypto gdoi‖ command on the group member. After the GM or if all policy is delete successfully registers to the KS, GM will keep that downloaded policy even if future re - registrations fail and IPSec SAs have expired. If Fail - Close is not configured on the group me mber, Fail - Open is the default behavior. With both Fail - Close and Fail - Open modes, the GM keeps the policy it received from previous successful registration. For Fail ecessary close ACL has to be configured with all n - Close mode to work correctly, a ―complete‖ fail - deny ACEs for cleartext traffic. An example of an incomplete configuration is shown below: ip access - list extended ACL_FC <=== Incomplete ACL with no ACEs list extended ACL_L2L - ip access 192.168.1.1 deny ip host host 10.1.1.1 y permit ip any an ... close - crypto map 10 gdoi fail ! Incomplete <==== ! Match address is not configured match address ACL_FC An example of a complete configuration is shown below set tset1 esp crypto ipsec transform - - aes esp - sha256 - hmac crypto map TEST gdo i fail - close match address 110 activate - isakmp crypto map TEST 10 ipsec match address 120 set peer 10.1.1.2 set transform - set tset1 crypto map TEST 20 gdoi match address 130 set group ks1_group close ACL is always matched LAST i.e. the order is as follows: - In the above example, the Fail ACL 110  ACL 130  ACL 120 of Page 49 220 © 2018 Cisco Systems, Inc. Cisco Confidential/Proprietary GETVPN Design and Implementation Guide

50 All traffic that does not match any of the ACLs will be dropped. ACL 110 will add an implicit ―Permit ip any any‖ This implicit entry i Close mode. Permit means - s added because the crypto map is configured in Fail traffic will be dropped and deny means traffic will go in clear. - registration 3.6.5 Group Member Re ey message from KS after a - GM starts the re registration process to the KS when it does not receive a rek certain time. 3.6.5.1 Group Member Re - registration Values 5% of re MAX (5% of TEK Lifetime, 60s) timer value is calculated as the The new - registration , that is, if 60s will be used. The jitter value is added as the TEK Lifetime is less than 60s, the minimum default value of a random number: RND ( - 6s to 6s). Example below shows the calculation for the re registration timer for a large TEK lifetime of 3600 seconds: - TEK Lifetime(T) = 3600 seconds MAX(5% registration time value is - Re of T = 180s, 60s) = 180s 6s to 6s) Jitter value is RND ( - 6s) to (T Re 180s+6s) - - - registration in initiated for GM between (T - 180s - The figure below illustrates the timer value as calculated in the example above. The GM re registration timer is shown in relat ion to the KS rekey time which is MAX(10% of T= 360s, 90s) = 360s and also the time at which the TEK on the GM expires. Figure 8. Figure shows the reregistration timer values when calculated with an example of TEK Lifetime equal to 8 3600 seconds registration timer for a small TEK lifetime of 800 seconds: Example below sh ows the calculation for the re - TEK Lifetime(T) = 800s Re - registration time value is MAX(5% of T = 40s, 60s) = 60s Jitter value is RND( - 6s to 6s) 60s Re - registration time window for GM is from (T s) to (T - 60s+6s) 6 - - registration timer - The figure below illustrates the timer value as calculated in the example above. The GM re is shown in relation to the KS rekey time which is MAX(10% of T = 80s, 90s) = 90s and also the time at pires. which the TEK on the GM ex of Page 50 220 © 2018 Cisco Systems, Inc. Cisco Confidential/Proprietary GETVPN Design and Implementation Guide

51 Figure 9. Figure 9 shows the reregistration timer values when calculated an example of TEK Lifetime equal to 800 seconds 3.6.5.2 Group Member Re - registration Jitter Values change in re d as a random value of new jitter value is calculate registration value, the In addition to the MAX(2% of TEK Lifetime, 6s) , that is, if 2% of the TEK Lifetime is less than 6s, the minimum default value - 7%) to (T , - 5%) 5%, which is (T of 6s will be used. The re - registration time window becomes T - (5%+2%) to T - where 5% is the new registration time illustrated in section 3.6.5.1 above. The re - - registration timer value re remains MAX(5% of TEK Lifetime, 60s). registration timer and the jitter value for a large TEK lifetime - Example below shows the calculation for the re : of 3600 seconds TEK Lifetime(T) = 3600s registration time value is MAX(5% of T = 180s, 60s) = 180s - Re Jitter value is MAX(2% of T = 72s, 6s) = 72s - - registration in initiated for GM between (T Re 180s - 72s) to (T - 180s) value with jitter as calculated in the example above. The The figure below illustrates the re - registration timer - registration timer is shown in relation to the KS rekey time which is MAX(10% GM re of T= 360s, 90s) = 360s and also the time at which the TEK on the GM expires. Figure 10. - Figure 10 shows the re registra tion timer values with jitter for a TEK Lifetime equal to 3600 seconds Example below shows the calculation for the re - registration timer for a small TEK lifetime of 200 seconds: TEK Lifetime(T) = 200s Re - = 60s registration time value is MAX(5% of T = 10s, 60s) Jitter value is MAX(2% of T = 4s, 6s) = 6s 6s) to (T - 60s - registration is initiated for GM between (T - Re 60s) - of Page 51 220 © 2018 Cisco Systems, Inc. Cisco Confidential/Proprietary GETVPN Design and Implementation Guide

52 The figure below illustrates the timer value as calculated in the example above. The GM re - registration timer is shown in relation to the KS rekey time which is MAX(10% of T = 20s, 90s) = 90s and also the time at which the TEK on the GM expires. Figure 11. shows the re Figure 11 - registration timer values with jitter for a TEK Lifetime equal to 200 seconds ossible that the GM may first register and VPN module boots up, it is p Note: When a GM with ISM - - download the policy to the onboard crypto engine and then re e policy onto the register again to download th - VPN when the module boots up . ISM 3.6.5.3 Re - registration Differences Between G - IKEv2 and GDOI ansmission for GDOI Registration Failure IKEv1 Retr  o IKEv1 uses constant retransmission interval (3x 10 sec + 10 sec backoff) o GDOI uses exponential backoff (70, 140, 280, 480) - IKEv2 Registration Failure IKEv2 Retransmission for G  o retransmission (2, 4, 8, 16, ...) IKEv2 uses an exponential backoff for IKEv2 caps retransmission at 4 (2+4+8+16 = 30 sec + 10 sec backoff) - G o IKEv2 uses same backoff (70, 140, 280, 480) at end of KS list - G o 3 . 6 . 6 GETVPN KEK Rekey Behavior Changes EK This section describes GETVPN K Encryption Ke y (KEK) rekey behavior changes in Cisco IOS Release these releases 15.2(1)T) and Cisco IOS XE Release 3.5S/15.2(1)S) (corresponding GDOI version) . Prior to , the KEK rekey is sent by the Key Server (KS) when a current KEK expires. The Group Member (GM) does not maintain a timer to keep track of the remaining lifetime of the KEK. The current KEK is replaced by a new KEK only when a KEK rekey is received. If the GM does not receive a KEK rekey at the expected KEK retains the allowing the expiry, it does not trigger a reregistration to the KS, and it will existing KEK without expire. This that here is no command T result in the KEK being used after its configured lifetime. may KEK to KEK. lifetime of the remaining can be used on the GM that display s the ey Server Behavior 3.6.6.1 K Cisco IOS Release 15.2(1)T and Cisco IOS Effective with XE Release 3.5S/15.2(1)S – (corresponding the following he new KEK rekey behavior includes changes: , t GDOI version h like a Traffic Exchange Key -  On the KS KEK rekeys are sent before the current KEK expiry, muc (TEK) rekey. - On the GM  The GM maintains a timer to keep track of the remaining KEK lifetime and triggers a reregistration if the KEK rekey is not received. of Page 52 220 © 2018 Cisco Systems, Inc. Cisco Confidential/Proprietary GETVPN Design and Implementation Guide

53 With the new rekey behavior, the KS starts a KEK rekey before the cu rrent KEK expiry according to the below formula. KEK rekey time = KEK lifetime – (200 + (number of retransmissions x retransmission interval) + (5 x (1 + Number of registered GMs/50) ) is used with a unicast portion GMs/50) Note: In the above formula , the 5 x (1 + Number of registered rekey. Per this behavior, a KS starts to rekey a KEK 200 seconds before the current KEK expires. After the rekey is sent, the KS starts to use the new KEK for all subsequent TEK/KEK rekeys. 3.6.6.2 Group Member Behavior Effective wit h Cisco IOS Release 15.2(1)T and Cisco IOS - XE Release 3.5S/15.2(1)S) , t he new GM behavior includes the following changes: 1. GM enforces a KEK lifetime expiry by adding a timer to keep track of the KEK remaining lifetime. When that timer expires, the KEK is d eleted on the GM and a reregistration is triggered. timer is added . A 2. GM expects a KEK rekey to occur 200 seconds before the current KEK expires registration is triggered - KEK is deleted and a re a so that so that new KEK is not received when a 200 seconds before the current KEK expires . This KEK deletion and reregistration event happens - 40 seconds). in the timer interval of (KEK expiry - 190 seconds, KEK expiry KEK Along with the functional changes, the GM show command outputs are also modified to display the remaining lifetime accordingly. GM# show crypto gdoi GROUP INFORMATION Group Name : G1 Group Identity : 3333 Crypto Path : ipv4 Key Management Path : ipv4 Rekeys received : 0 PSec SA Direction : Both I Group Server list : 10.1.11.2 Group member : 10.1.13.2 vrf: None Version : 1.0.4 Registration status : Registered ered with : 10.1.11.2 Regist Reregisters in : 81 sec <=== Reregistration due to TEK or KEK, whichever comes first Succeeded registration: 1 Attempted registration: 1 Last rekey from : 0.0.0.0 : 0 Last rekey seq num of 220 Page 53 © 2018 Cisco Systems, Inc. Cisco Confidential/Proprietary GETVPN Design and Implementation Guide

54 Unicast rekey received: 0 Rekey ACKs sent : 0 Rekey Received : never allowable rekey cipher: any allowable rekey hash : any allowable transformtag: any ESP Rekeys cumulative Total re ceived : 0 After latest register : 0 Rekey Acks sents : 0 ACL Downloaded From KS 10.1.11.2: list deny ospf any access - - access list deny eigrp any any list deny udp any port = 848 any port = 848 - access access t deny icmp any any lis - list permit ip any any - access KEK POLICY: Rekey Transport Type : Unicast <=== Running timer for remaining KEK lifetime Lifetime (secs) : 56 Encrypt Algorithm : 3DES Key Size : 192 Sig Hash Algorithm : HMAC_AUTH_SHA Sig Key Length (bits) : 1024 TEK POLICY for the current KS - Policy ACEs Downloaded: Serial1/0: IPsec SA: spi: 0xD835DB99(3627408281) sha - 3des esp - transform: esp hmac - sa timing:remaining key lifetime (sec): (2228) Anti - Replay(Time Based) : 10 sec interval 6.3 Interoperability Issues . . 3 6 the GM and the KS to one of the To avoid interoperability issues, it is recommended that you upgrade versions supporting the new KEK rekey behavior. If the GM is running the older code, and the KS is running the software version , the KS sends out the KEK rekey prior to the KEK expiry and there is no additional functional impact. However, if a GM running the with a KS running the older code, the GM may incur two Group Domain of newer code registers of Page 54 220 © 2018 Cisco Systems, Inc. Cisco Confidential/Proprietary GETVPN Design and Implementation Guide

55 Interpretation (GDOI) reregistrations to receive the new KEK per KEK rekey cycle. The following events occur when this happens: the KS will only send the KEK rekey when 1. The GM reregisters before the current KEK expiry, since the current KEK expires. The GM receives the KEK, and it is the same KEK as the one it currently has with less than 190 seconds lifetime remaining. This tells the GM that it is registered with a KS without the KEK rekey change. - %GDOI 4 - GM_RE_REGISTER: The IPSec SA created for group G1 may register to KS. have expired/been cleared, or didn't go through. Re - %CRYPTO GM_REGSTER: Start registration to KS 10.1.11.2 for - 5 - group G1 using address 10.1.13.2 GM %GDOI - 5 - _REKEY_TRANS_2_UNI: Group G1 transitioned to Unicast Rekey. SA_KEK_UPDATED: SA KEK was updated %GDOI - 5 - %GDOI - SA_TEK_UPDATED: SA TEK was updated 5 - - %GDOI - 5 GM_REGS_COMPL: Registration to KS 10.1.11.2 complete for group G1 using address 10.1.13.2 - GM_INSTALL_POLICIES_SUCCESS: SUCCESS: Installation of 5 %GDOI - Reg/Rekey policies from KS 10.1.11.2 for group G1 & gm identity 10.1.13.2 The GM deletes the KEK at its lifetime expiry, and sets a reregistration timer of (KEK expiry, KEK 2. expiry + 80). - GM_DELETE_EXPIRED_KEK: KEK expired for group G1 and was deleted - 5 %GDOI 3. When the reregistration timer expires, the GM reregisters and will receive the new KEK. %GDOI - 4 - GM_RE_REGISTER: The IPSec SA created for group G1 may register to KS. have expired/been cleared, or didn't - go through. Re %CRYPTO 5 - GM_REGSTER: Start registration to KS 10.1.11.2 for - group G1 using address 10.1.13.2 %GDOI - 5 - GM_REKEY_TRANS_2_UNI: Group G1 transitioned to Unicast Rekey. SA_KEK_UPDATED: SA KEK was updated - 5 - %GDOI SA_TE - 5 %GDOI - K_UPDATED: SA TEK was updated %GDOI - 5 - GM_REGS_COMPL: Registration to KS 10.1.11.2 complete for group G1 using address 10.1.13.2 - 5 %GDOI - GM_INSTALL_POLICIES_SUCCESS: SUCCESS: Installation of Reg/Rekey policies from KS 10.1.11.2 for group G1 & gm ide ntity 10.1.13.2 GM Error Detection 3.6.6.4 GETVPN Resiliency - feature detects erroneous packets in the data - /Error Recovery Resiliency GM Error Detection GETVPN The - Based Anti - plane for each Group Domain of Interpretation (GDOI) group such as invalid SPIs or Time . Replay (TBAR) errors. These errors are tracked, and the outer source IP address of the packet is recorded The KS encodes the group information in the SPI (Security Parameter Index) and then it downloads it via the TEK policy to the GM. of Page 55 220 © 2018 Cisco Systems, Inc. Cisco Confidential/Proprietary GETVPN Design and Implementation Guide

56 - shows how to enable the group member (GM) to monitor for control lowing The fol configuration snippet plane errors every 300 seconds. crypto gdoi group GETVPN identity number 1111 server address ipv4 1.0.0.2 client recovery check interval 300 - GM Error Detection feature, a syslog message is - s detected by the GETVPN Resiliency When a failure i generated to show the source IP address of the erroneous packet: - TIMEBASED_REPLAY_FAILED: An anti replay check has failed in group - %GDOI 4 address 1 - 00.0.0.9. my_pseudotime is 600006.78 GETVPN from sourceip secs,peer_pseudotime is 500033.34 secs, replay_window is 100(second) PKT_REPLAY_ERR: decrypt: replay check failed - 4 - *Feb 10 21:01:56.043:%CRYPTO connection id=29, sequence number=11 fy that this GM recovery reregistration feature is triggered. For A syslog message is generated to noti plane errors every 300 seconds, when the recovery - instance, if you configure the GM to monitor for control registration occurs the following syslog is generated: *Feb 23 19:06:28.600: %GDOI - 5 - GM_RECOVERY_REGISTER: received invalid GDOI packets; register to KS to refresh policy, keys, and PST . Note: Error Detection is not supported on ASR1000 GM. on this feature, refer to . GM Error Detection feature - GETVPN Resiliency For more information COOP Design Considerations 3.7 GETVPN KSs are supported by GETVPN COOP KSs provide redundancy to . Multiple to ensure redundancy, high availability (HA), and fast recovery in case of network failure. The primary KS is responsible for creating and distributing group policy. It also periodically sends out group ll other KSs to keep those servers in synchronization. If the secondary KSs information updates to a somehow miss the updates, they contact the primary KS to directly request information updates. The secondary KSs mark the primary KS as unreachable (that is, ―dead‖) s are not received for an extended period of time. if the update Cooperative GDOI KSs can jointly manage the GDOI registrations for the group, which achieves load balancing during GM registration process. When a new policy is created on a primary KS, distribute rekey messages to GDOI GMs regardless of which KS a GM is registered with. the primary KS to group basis which means theoretically a KS - Note: IOS supports COOP configuration on per can peer with different COOP KSs for different groups. A KS can be a primary for one gr oup but secondary for a different group. of Page 56 220 © 2018 Cisco Systems, Inc. Cisco Confidential/Proprietary GETVPN Design and Implementation Guide

57 3.7.1 COOP Messages COOP KSs use announcement messages to communicate with each other. These messages are KS messages are secured using Phase I - to - exchanged on UDP port 848, as defined for GDOI. All KS tiated keys. (ISAKMP) nego Primary KSs periodically send announcement messages to the secondary KSs. These messages enable the KSs to exchange state information about GMs and policies. The various components of these messages are:  KS sender priority This value describes the priority of the sender, which is configurable using the CLI. The KS with the highest priority becomes the primary KS. If two KSs have the same priority, the KS with the highest IP address becomes the primary KS.  KS role f a KS (primary or secondary).Group policies  This value describes the role o Group policies are maintained for a group and include information such as GM information and IPsec SAs and keys. 3.7.1.1 COOP Message Size umber of GMs in the system The announcement messages list GMs and communicate group policies. The n can significantly impact message size. Message size also depends on the number of SAs distributed in group policies If the number of GMs in the system is quite large, the KS system buffers should be large enough he large messages. This can be done by increasing huge buffer size on the KSs. See to accommodate t 8 for recommendations for increasing the KS buffer size to handle large messages. 3.7.3. 2 To understand the impact on the UDP payload size with increasing number of GMs, see F . igure 1 Figure 12. COOP Message Size by Number of GMs of Page 57 220 © 2018 Cisco Systems, Inc. Cisco Confidential/Proprietary GETVPN Design and Implementation Guide

58 eight denies and one permit), Figure — For a fixed size group policy configured on the KS (nine lines of ACL shows how message size increases with the number of GMs. For 2000 GMs, the size of the update 11 mes sage (UDP payload only) is approximately 25000 bytes. Large message sizes mean that messages undergo fragmentation. The encryption module at 13 the KS must be able to handle the large number of fragments. Using the same test configuration, Figure shows ho w fragments increase with the increase in number of GMs. For 2000 GMs, for example, the message is contained in 17 fragments. Figure 13. COOP Message Fragments by Number of GMs 3.7.2 COOP States and Timers COOP KSs maintain various state and role information abou t peer KSs. 3.7.2.1 Local KS Information primary role. In a given GDOI group, only one secondary or A COOP KS can operate in either a KS can operate in a primary role. This assumes that all COOP KSs can exchange announcement messages ection. The role election is based on the priority value configured on each KS. 3.7.3.2 and perform a role el ―Setting KS Priority‖ describes priority configuration and some design considerations for selecting the local KS priority. owing show command. The following examples show typical To see the current role of a KS, use the foll differences in priority and role. For a primary KS: KS1#show crypto gdoi ks <..> : 100 Local Priority Local KS Status : Alive of Page 58 220 © 2018 Cisco Systems, Inc. Cisco Confidential/Proprietary GETVPN Design and Implementation Guide

59 : Primary Local KS Role For an operational secondary KS: KS2#show crypto gdoi ks <..> : 50 Local Priority Local KS Status : Alive Local KS Role : Secondary 3.7.2.2 Peer KS Information Along with information about its own state, a COOP KS maintains role and status information for peer KSs. h announcement messages (see 3.7.1 ―COOP Messages‖). In normal This information is exchanged throug operation, COOP messages are sent only from the primary KS to the secondary KSs. The primary KS has all KSs no COOP mechanism to obtain the status of secondary KSs. Periodic DPDs must be configured on GETVPN in the network so the primary KS can correctly identify secondary KS states. Periodic DPDs are not supported between GMs and KS. 3.7.2.2.1 Peer Status A primary KS accurately shows the status of peer secondary KSs after KS role negotiation. For a primary KS, the peer status field can have the following values: Alive: A peer KS, operating in secondary role, is operational  Dead: A peer KS is unreachable  of the primary A secondary KS does report the state of another secondary KS. It tracks only the status not KS (either Alive or Dead). All other non - primary peer KS are reported as having ̳unknown‘ status. When a KS initializes, it comes up as a secondary KS. Hence, even a KS that will become the Note: primary KS, initially reports other peer KSs as ̳u nknown‘. : Secondary KS shows all non Tip - primary peer KSs status as unknown. The following example shows peer KS states as reported by a primary KS for two secondary KSs. KS1#show crypto gdoi ks coop <..> Peer Sessions: Session 1: 51 Server handle: 21474836 Peer Address: 1 72.18.5.2 Peer Priority: 50 Peer KS Role: Secondary, Peer KS Status: Alive Antireplay Sequence Number: 15 of Page 59 220 © 2018 Cisco Systems, Inc. Cisco Confidential/Proprietary GETVPN Design and Implementation Guide

60 IKE status: Established <..> Session 2: Server handle: 2147483652 Peer Address: 1 72.20.4.2 Peer Priority: 85 ary, Peer KS Status: Alive Peer KS Role: Second Antireplay Sequence Number: 3345 IKE status: Established <..> 3.7.2.2.2 Peer Role A KS reports the peer KS role as either primary or secondary. There can be only one active ( ̳Alive‘) primary ll KS can communicate with each other. As seen in the preceding KS in a given GDOI group, assuming a example, a primary KS reports the peer KS role of two secondary KSs. If a KS reports more than one primary KS, a failure condition is indicated. Consider a scenario with three COOP KSs, where KS1 is the primary KS, and KS2 and KS3 are the secondary KSs. If KS2 were to lose communication with the active primary KS (KS1) and the second secondary KS (KS3) is elected as the primary KS, the secondary KS (KS2) would report two primary KSs. However, o ne would be ̳Alive‘ and the other would be ̳Dead‘. See the following snippet: cry gdoi ks coop KS2 #sh <..> Peer Sessions: Session 1: Server handle: 2147483651 172.16.4.2 Peer Address: Peer Priority: 1 Peer KS Role: Primary , Peer KS Status: Dead y Sequence Number: 27447 Antirepla IKE status: Failed <..> of Page 60 220 © 2018 Cisco Systems, Inc. Cisco Confidential/Proprietary GETVPN Design and Implementation Guide

61 Session 2: Server handle: 2147483652 Peer Address: 172.20.4.2 Peer Priority: 85 Peer KS Role: Primary , Peer KS Status: Alive Antireplay Sequence Number: 30 IKE status: Established <..> 3.7.2.3 Peer KS Rol e Transitions A secondary KS can transition to a primary KS state under the following circumstances:  During a COOP election process where no KS has declared itself primary KS for the group, if a secondary KS detects no other higher priority KS, that KS tra nsitions to primary KS role  If a secondary KS stops receiving announcement messages from the primary KS, the secondary KS transmits an announcement message to all known peers. If no responses are received, the KS transitions to the primary KS role. This i s commonly seen when the network is partitioned so that one or more KSs are isolated (see 3.7.4.2 ―Network Split and Merge‖). After a peer KS is elected as a primary KS, very few scenarios could cause it to switch to a secondary role. a such cause could that scenario only the ation, initializ for Except downgrade is detection of a higher priority primary KS. This is commonly seen after a network partition is resolved (see 3.7.4.2 ―Network Split and Merge‖). following circumstances: A COOP KS can assume the secondary role under the Upon initialization (for example, after a reload, a KS always comes up in secondary state).   During a COOP election process, a secondary KS that detects a higher priority KS retains its secondary state.  econdary role detects a lower priority KS in primary role, the higher If a higher priority KS in s priority KS will not preempt, and retains its secondary state. 3.7.2.4 COOP Timers and Parameters also This section describes COOP timers and parameters. The default values of the timers are . In most cases, these timer values should not be changed the recommended values. In addition to the COOP timers described in this section, the timer is also important in ISAKMP SA lifetime the COOP scenario. See 3.5.1 ―ISAKMP‖ for more details and co nfiguration information. 3.7.2.4.1 Primary Refresh Timer Default: 20 seconds The primary KS sends an announcement message to all active secondary KSs every interval defined by this timer. To configure this timer: 220 Page 61 of © 2018 Cisco Systems, Inc. Cisco Confidential/Proprietary GETVPN Design and Implementation Guide

62 ! crypto gdoi group server loc al redundancy protocol timeout refresh ! 2 3.7.2.4. Secondary Periodic Timer Default: 30 seconds If a secondary KS does not receive a periodic announcement message from the primary KS during this essages with a return flag, to all KSs in the group. interval, the secondary KS sends announcement m To configure this timer: ! crypto gdoi group server local redundancy protocol timeout periodic ! 3.7.2.4.3 Retry Count Default: 2 that a secondary KS sends an announcement message to all This parameter specifies the number of times KSs when it does not receive a periodic message from the primary KS. After this count, the secondary KS reevaluates its role based on the replies it receives. To configure this parameter: ! doi group crypto g server local redundancy protocol retransmit 3.7.2.4.4 Policy Update Timer - Fixed period: 5 seconds (non configurable) When a primary or secondary KS has a change in GM registration information, the KS must send a policy update message. This timer starts after a change in GM registration is detected. If other changes occur during this interval, all updates are sent together in one announcement message. of Page 62 220 © 2018 Cisco Systems, Inc. Cisco Confidential/Proprietary GETVPN Design and Implementation Guide

63 3.7.3 COOP KS Design Considerations ions related to COOP: the number of KSs, KS priority, load balancing, There are several design considerat and more. It is imperative that the same GETVPN policies be configured on all of the COOP KS serving a group. This section describes these design considerations in more detail. electing the Number of COOP KSs 3.7.3.1 S single KS, Even in a multiple COOP KS setup, only the primary KS is responsible for sending out rekeys. A have at least 2 COOP although sufficient, can be a single point of failure in the system. It is recommended to is also recommended to use as few KSs as necessary to scale the KSs. It network and provide control plane resiliency. As the number of GMs increase, it might become desirable to place KSs in geographically dispersed locations, such as different data center (DC) s ites. One way to arrange or place the KSs is to have 2 KSs on a single site, and to place 1 other KS at a different geographical site. This type of placement provides redundancy for different failure scenarios. It is recommended to place the KS in parallel with the GM as opposed to behind the GM because a GM failure can block the access to the KS. However, placing a KS behind a GM is feasible if policy exceptions are addressed to ensure reliable COOP and GDOI protocol exchanges. The maximum number of COOP K Ss in a group is seven. Note that having so many KSs in one group does not provide much benefit other than redundancy and registration load balancing. For this guide, four COOP KSs were tested. n on a given KS: To configure multiple COOP KSs, use the following configuratio ! crypto gdoi group server local redundancy peer address ipv4 peer address ipv4 peer address ipv4 ! 3.7.3.2 Setting KS Priority red on each KS. The KS having the highest priority COOP role election is based on the local priority configu is elected as the primary KS and all other KSs operate in secondary mode. If the KS with the highest priority fails, the secondary KS having the next highest priority takes over. The order in which a KS ca n assume the primary role is important. By default, the local priority on a KS is 1. If multiple KSs have the same priority, the KS with the highest IP address wins the election. Site A and Site B, as To explain how priorities can be chosen, consider a scenario with two sites, shown in 14 Figure the same group. . Assume that each site has two KSs, so four KSs operate cooperatively in of Page 63 220 © 2018 Cisco Systems, Inc. Cisco Confidential/Proprietary GETVPN Design and Implementation Guide

64 KS Priority Selection Scenario Figure 14. If resiliency against failed hardware or local site network failure (such as LAN segments) is most critical, KS priorities can be chosen as follows: site_A_KS1 > site_A_KS2 > site_B_KS1 > site_B_KS2 In this case, with Site A as the primary site, site_A_KS1 is the first choice for primary KS. However, it is this KS or KS hardware to fail. Therefore, it is preferable to have more likely for the local LAN segment of site_A_KS2 as the next choice for primary. In some systems, resiliency against site failures is most critical. In this case, priorities for the KS can be chosen as follows: KS1 > site_A_KS2 > site_B_KS2 site_A_KS1 > si te_B - In this case, Site A can be the primary site, with site_A_KS1 as the first choice for primary KS. If site A fails, it would be desirable to have a KS from site B as the next choice for primary. pends on user requirements and can be chosen in many different ways. These The order of priorities de values should be selected after careful thought and consideration. To configure the KS local priority, configure as shown for each COOP KS. ! crypto gdoi group identity number 12345 server local . 72 . 6 2 .1 address ipv4 1 4 redundancy - 255> local priority <1 ! 3.7.3.3 Balancing GM Registrations among COOP KSs The primary KS is responsible for distributing rekeys to the entire system. However, GMs can register with any KS in given GDOI group. Because COOP KSs periodically synchronize their policy database, this gives balancing ability to the KSs. - load of Page 64 220 © 2018 Cisco Systems, Inc. Cisco Confidential/Proprietary GETVPN Design and Implementation Guide

65 Whenever a KS (primary or secondary) receives a new GM registration, the KS sends an announcement ormation for the new GM to the other KSs. This way, message with policy inf all KSs maintain the same complete GM database. Load balancing of GMs can be achieved in the following ways: ● - Load balancing using configuration ● - Load balancing using routing ● ad balancing (SLB) balancing using server lo Load - 3.7.3.3.1 Load Balancing using Configuration One set of GMs can be configured to register with KS1, another set with KS2 and so on. GMs - balancing for registration messages. However, if one KS fails, the associated set of This provides load can lose connectivity, as shown in Figure 15 (a). To prevent this, each GM can be configured with all KSs. Each GM then attempts to register with the KSs in the list, and so on. order of the configuration. If a GM cannot reach the first configured KS, it tries the next in - Load balancing can be configured so that one set of GMs has KSs configured in the order KS1, KS2, KS3, KS4. Another set of GMs has KSs configured in the order KS2, KS3, KS4, KS1. In this way, all KSs are balancing and redundancy, as shown - ll KSs are operational, we can have load available to all GMs, but if a (b). in Figure 15 Load balancing can also be accomplished using a combination of these scenarios: one group of GMs is configured with KS1 and KS2, while another set of GMs is confi gured with KS2 and KS3 and so on, as (c). 15 shown in Figure - Load Figure 15. Balancing GMs on Multiple COOP KSs. of Page 65 220 © 2018 Cisco Systems, Inc. Cisco Confidential/Proprietary GETVPN Design and Implementation Guide

66 To configure multiple KSs on a GM: ! crypto gdoi group server address ipv4 server address ipv4 ress ipv4 server add server address ipv4 ! 3.7.3.3.2 Load Balancing using Routing (Anycast) If each KS shares the same registration IP address, a GM trying to reach that IP address would balancing function is passed to the - his scenario, the load automatically be routed to the nearest KS. In t routing. The advantage of this method is that GM configuration is simplified; only one KS IP address must be balancing can only be controlled via routin - g. Different configured at the GM. At the same time, load combinations of load balancing shown in Figure 14 might not be possible using this method. Routing should be designed carefully so that each GM can reach all of the KS loopback interfaces. Figure 16 shows how load - balancing is achieved using r outing. As shown, all KSs have the same IP address on a loopback interface. As this loopback address is distributed to the network, routing determines the closest KS based on routing policies. Figure 16. Load Balancing GM Registrations using Routing K ) y r a d n o c e s ( 2 S o 0 o L 0 . 1 . 1 ) y r a m i r p ( 1 . 1 k : 1 c a b p S K 1 . 0 1 : 0 L c a b p o o L 1 . o o p b a 1 . 1 . 1 . 8 1 . 2 7 1 : 1 k c k b 1 . 1 . 7 1 . 2 7 1 : 1 k L o o p c a 1 G M c 3 ( s e y o n d a r K S ) 1 L o o p b a c k 0 : 1 0 . 1 . 1 . : 1 . 9 1 . 2 7 1 1 1 k c a b p o o L . R e g i s t r a t i o n r e q u e s t t ( n d l e d b y r o u a i n g ) h 2 M G On the GMs, only one KS must be configured. ! crypto gdoi group GETVPN 66 of 220 Page © 2018 Cisco Systems, Inc. Cisco Confidential/Proprietary GETVPN Design and Implementation Guide

67 .1.1.1 server address ipv4 1 0 ! On the KSs, two loopback interfaces must be configured. One loopback interface has the same IP address across all KSs used specifically for registration, while the other loopback interface has distinct IP addresses for the COOP KS functionality and for responding to registration messages. The following configuration is from KS1 as depicted in Figure . 16 ! ! Common IP address interface Loopbac k0 ip address 1 0 .1.1.1 255.255.255.255 ! ! Distinct IP address interface Loopback1 72 ip address 1 .1 255.255.255.255 7 .1 ! crypto gdoi group GETVPN identity 12345 server local registration interface Loopback 0 72.17 .1.1 address ipv4 1 redundancy ocal l priority 255 72.18 .1.1 peer address ipv4 1 peer address ipv4 1 72.19 .1.1 ! 3.7.3.3.3 Load Balancing using SLB SLB provides yet another method for load balancing. If redundant COOP KSs are placed at a site, an SLB device can load - ons to multiple KSs accessed using a single virtual IP address (VIP). The balance registrati GMs are aware only of this VIP address, which simplifies configuration and transfers the load balancing functionality to a separate device. eve load balancing. As shown, all KSs have the same shows how an SLB device can achi 17 Figure IP address on a loopback interface, which is also configured on the SLB device as a virtual IP address (VIP). of Page 67 220 © 2018 Cisco Systems, Inc. Cisco Confidential/Proprietary GETVPN Design and Implementation Guide

68 Figure 17. Load Balancing GM Registrations Using SLB ) y r a d n o c e S K 2 S K ) y r a m i r P ( 1 S ( . 6 1 o 1 . 4 . 6 1 . 2 7 1 : 0 p o o L o L . 2 7 1 : 0 p 4 1 . R l a e r m o r f t n e s s y e k e d a e r d s s o f t h e K e y 1 1 . 4 . 7 1 . 2 7 . 4 . 2 2 . 1 7 7 1 e e r r S s v r e B a l a S c e r v e r L o a d n V i . 4 . 6 1 . 2 7 1 : P I l a u 1 r t V a P I l a u t r i s e s u s M G l l A a d d r e s s K e y S e r v e r 1 2 M G M G On the GMs, only one KS must be configured. ! crypto gdoi group GETVPN server address ipv4 172.1 6.4 .1 ! On the SLB device, such as a Catalyst 6500 employing Cisco IOS SLB, a server farm is created that identifies the unique IP addresses of the KSs as ―reals‖. A virtual server is created for GDOI protocol and is assigned the same IP address as the common loopback IP address on the KSs. ! !define a probe mechanism for the KSs - ip slb probe PING PROBE ping faildetect 3 ! !define a server farm to identify the KSs FARM - ip slb serverfarm 7200 predictor leastconns failaction purge PROBE - probe PING 220 Page 68 of © 2018 Cisco Systems, Inc. Cisco Confidential/Proprietary GETVPN Design and Implementation Guide

69 ! !KS - 1 .1 72.17.4 real 1 weight 1 maxconns 500 inservice ! - 2 !KS 72.17.4 real 1 .2 weight 1 maxconns 500 inservice ! !define a virtual server for GDOI protocol (UDP 848) ip slb vserver GDOI .1 udp 848 virtual 1 72.16.4 - FARM serverfarm 7200 no advertise idle 900 inservice ! On the KSs, use the unique IP addresses to define the local server and peer KSs. The following . 7 configuration snippet is for KS1 as shown in Figure 1 ! crypto gdoi group GETVPN server local address ipv4 1 .1 72.17.4 redundancy .2 72.17.4 peer address ipv4 1 ! Timers for registration failover to alternate Key Servers 3.7.3.4 first KS ster with the When a GM is configured with more multiple KSs in the group, it will try to regi configured and will move to the subsequent KSs GM The . will wait for a in case the registration fails in as IKE backoff timer) is n specified time before trying to register wit h the next KS. This wait time (also know of Page 69 220 © 2018 Cisco Systems, Inc. Cisco Confidential/Proprietary GETVPN Design and Implementation Guide

70 40seconds till the GM reaches the last configured KS. In case the registration is not successful with any of the KSs in the first pass, the GM will retry the registration process with the first KS after waiting for 70seconds. The wait time between passes is known as the GDOI backoff timer. In the second pass, the GM will try to register with the KS s in the order of configuration . Similar to the first second pass, the pass, the GM will wait for 40seconds between registrations. However, at the end of t he GDOI backoff timer seconds ( i.e. , the GM will now wait for 140 seconds before restarting the will now be 140 third pass). The GM will keep trying to register with the KSs till a successful registration. The GDOI backoff timer will keep doubling after every pass till it rea ches a maximum value of 480seconds. The following table summarizes the registration failover timers. Let us assume the GM is configured with 3 KSs (KS1, KS2 and KS3). The wait times between registrations are shown below: time Wait d to register Registration Faile Timer type Pass with KS (seconds) Failure # 1 KS1 40 IKE backoff 1 KS2 2 40 IKE backoff 3 KS3 70 GDOI backoff 2 4 KS1 40 IKE backoff IKE backoff 40 KS2 5 6 140 GDOI backoff KS3 3 KS1 40 IKE backoff 7 KS2 40 IKE backoff 8 9 KS3 280 G DOI backoff 4 10 KS1 40 IKE backoff IKE backoff 11 KS2 40 480 KS3 12 GDOI backoff <== Max backoff value 5 (and IKE backoff 13 KS1 40 higher) 40 14 KS2 IKE backoff 15 KS3 480 GDOI backoff <== Max backoff value 3.7.3.5 Identical Policies on all KS s With multiple COOP KSs, the policies configured on each KS must be considered. T he same the K ey of S erver s. GETVPN GETVPN policies should be configured on each If a different COOP KS assumes the primary role y message to it should distribute the same rules in a reke ; of Page 70 220 © 2018 Cisco Systems, Inc. Cisco Confidential/Proprietary GETVPN Design and Implementation Guide

71 the GMs. If the policies were different, the GMs would receive different policies whenever a different KS is elected as primary. This can cause disruption. quired, the order of To minimize the time that inconsistent policies exist on KSs when policy changes are re change to the policy is important. When policy is changed on a primary KS, the new policy is immediately distributed to the GMs for execution. If a secondary KS has the old policy, any GM registering with the secondary KS receives the old policy. However, the GMs receive the new policy during the rekey process that occurs at the expiration of the TEKs associated with the new policies (by default, TEKs expire after an hour). e on all secondary KSs. Subsequently, Therefore, it is recommended to first make the new policy chang policy change on the primary KS forces all GMs to use the new policy as a result of a rekey. If a GM s registers before the policy change is executed on the primary KS, that GM will use the new policy as defined on a se condary KS. However, if a rekey occurs before making the changes to the primary KS policy, the old policy would be applied to all GMs even if they received the new policy during registration Tip es should be applied near the end of the : To minimize the potential policy discrepancies, policy chang TEK lifetime, but before rekey). See 2.2.4 ―Configuring Access List Policies‖ for more information about configuring KS policies. RSA Key on COOP KSs 6 3.7.3. eys are generated only on KSs and are used GETVPN KSs require RSA keys to create KEK keys. In , RSA k to authenticate and sign rekey messages. The KS creates a RSA public and private key pair. The public key he is downloaded to all GMs at registration. The KS signs the rekeys with the private key and all GMs verify t rekey messages using the public key. . If a KS is added to the group without the RSA key, the The RSA key pair must be identical on all KSs - new KS cannot create policies. The new KS can still register GMs, but without policies, GMs stay in a fail closed mode with no lifetime expiration. Any GMs that registered to the new KS would have to be cleared using clear crypto gdoi and then register to a KS with a valid RSA key. Tip ach group. : If a KS supports multiple groups, a unique RSA key pair can be established for e The RSA key must be synchronized to all KSs. The easiest method is to generate the RSA key on the first KS and make the RSA exportable. Then, save the RSA key (public and private) on a secure backend system. As KSs are added, they can import th e key. See 2.4.1 ―Exporting and Importing RSA Keys‖ for configuration information for importing and exporting RSA keys. When using PKI, it is recommended to create a separate RSA key for PKI purposes. This enables Note: modification of the PKI keys without affec ting COOP between the KS. This is also true for modification of the RSA key used for COOP on the KS. 7 3.7.3. Network Convergence before COOP Election If routing or network convergence takes place before KS COOP peer detection, routing convergence minimall y impacts COOP. However, if network convergence takes longer, some KSs cannot reach other KSs during COOP election. This might cause multiple KSs to be elected as primary (see 3.7.4 Failure Conditions for more details). Multiple primary KSs creates an arti ficial network partition and can lead to multiple rekeys being sent in a short interval after the network converges. of Page 71 220 © 2018 Cisco Systems, Inc. Cisco Confidential/Proprietary GETVPN Design and Implementation Guide

72 During regular operation of the COOP KSs, the KS COOP peer detection process should take longer than rgence interval. Failure to make the KS COOP DPD interval longer the expected routing and network conve than the routing convergence interval induces network instability by forcing a KS network partition, followed by a KS network merge. Buffer Size Configuration 8 3.7.3. With large number of GMs (1000+) and large policy statements, COOP and rekey message sizes can grow quite large (see 3.7.1.1 ―COOP‖ for COOP message sizes). Small buffers prevent messages from being transmitted efficiently and increase the potential for failed transmission of an nouncement and rekey messages. It is recommended to increase the HUGE buffer to its maximum value. To increase the HUGE buffer using CLI, use the following: ! buffers huge size 65535 ! Backup Link between KSs 9 3.7.3. se connectivity to each other. This might lead to multiple KS During a network split, COOP KSs may lo operating in primary mode. This results in GMs in different portions of the split network having different keys. While the GMs continue to operate, there are cases when GMs have complete connect ivity, but KSs can experience a network split that can lead to loss of communication between GMs. Whenever KSs lose connectivity with the primary KS, multiple rekeys might be exchanged in the system as new primaries are e. elected. This can be quite disruptiv To increase resiliency, it is highly recommended to provide multiple paths between the COOP KSs, such as with an out of band network backup. This path should not be inline with the data plane, and preferably a rovides a continuous channel between the COOP KSs, ensures separate link. This kind of a backup link p that they remain synchronized, prevents fluctuation in primary roles, and prevents unnecessary rekeys being sent. The disadvantage of using a backup link is that during the network split, certain G Ms might not be able to reach the primary KS (see 3.7.4.2 ―Network Split and Merge‖ for more information about how this impacts register with the next available KS, and this process continues if the network GMs). This causes GMs to re - registrations - failure is considerab ly long. As the number of GMs in the system increase, a large number of re might be seen periodically. To prevent this scenario, the backup link should facilitate rekey message distribution. This is easily accomplished using unicast rekey by ensuring that the GM IP identities are reachable through the backup link. Similarly, KS IP identities must be reachable to the GM via the backup link. If multicast is used, the multicast rekey must pass through the backup link. The method used to forward t he multicast rekeys on the backup link varies according the multicast architecture (PIM Sparse Mode (PIM SM), - - SSM), PIM Source Specific Mode (PIM - - PIM SM Anycast, and Multicast Source Discovery Protocol - ases. (MSDP)). PIM must operate on the backup link in most c registration by GM that - Failure to facilitate rekeys via the backup link results in persistent re cannot receive the rekey messages. of Page 72 220 © 2018 Cisco Systems, Inc. Cisco Confidential/Proprietary GETVPN Design and Implementation Guide

73 3.7.4 Failure Conditions iously This section explains some common failure scenarios that can be seen with COOP KSs. As prev explained, the primary KS is responsible for sending out the periodic rekeys while the secondary KSs maintain complete state information for GMs and are ready to take over if the primary KS fails. If a secondary KS takes over the primary role, the n ew primary KS sends rekeys to all GMs. If there are multiple transitions of primary role among COOP KSs, there can be many rekeys sent out in the network, which can be very disruptive. Therefore, t he above rekey occurs only at TEK expiry Multiple rekeys al so increases IPsec SAs at the GMs, which can lead to memory issues in some GMs. When there are many rekeys in a network, it is important to find the cause and resolve it immediately. Secondary KSs can lose connectivity with the primary KS for the following reasons: If the primary KS fails, a secondary KS takes over. : KS failure  A network split can lead to multiple KSs losing connectivity to the primary : Network partitioning  KS or other KSs. This can lead to multiple KSs declaring themselves as primary KSs. While this provides for redundancy, it can lead to problems from a network split, or from GMs that connect to multiple primary KSs. 3.7.4.1 KS Failure When Primary KS fails: update timer The primary KS sends an announcement message every 20 seconds (the default policy period). If this message is not received by a secondary KS, the secondary KS sends announcement messages to all peer KSs requesting a response. If there is no reply from the primary KS, the secondary KS the last announcement message is the primary KS. From the time with the highest priority takes over as received from the failing primary KS, it takes 90 seconds for a new KS to transition to primary state. 18 Figure shows secondary KS behavior just before it transitions to the primary state. of Page 73 220 © 2018 Cisco Systems, Inc. Cisco Confidential/Proprietary GETVPN Design and Implementation Guide

74 OP KS: Secondary to Primary Transition CO Figure 18. The following IOS snippets are from Secondary KS1. Initially, Sec - KS1 shows Pri - KS as active and Sec - KS2 as unknown - Sec show crypto gdoi ks coop KS1# <..> .1 72.16.4 Local Address: 1 Local Priority: 100 Local KS Role: Secondary , Local KS Status: Alive <..> Peer Sessions: Session 1: Server handle: 2147483651 72.16.4 .3 Peer Address: 1 Peer Priority: 1 Peer KS Role: Secondary, Peer KS Status: Unknown <..> Session 2: Server handle: 2147483656 of Page 74 220 © 2018 Cisco Systems, Inc. Cisco Confidential/Proprietary GETVPN Design and Implementation Guide

75 72.16.4 Peer Address: 1 .2 Priority: 175 Peer Peer KS Role: Primary , Peer KS Status: Alive <..> When Pri KS fails (hardware failure or reboot), Sec - KS1 later transitions to - primary state and sends a rekey to the GDOI group. The following syslog - KS1 are seen during thi s process:Sec - KS1# messages from Sec .1 in group 72.16.4 May COOP_KS_TRANS_TO_PRI: KS 1 7 10:21:25.327: %GDOI - 5 - 72.16.4 .2) dgvpn1 transitioned to Primary (Previous Primary = 1 72.16.4 May 7 10:21:30.328: %GDOI - 3 - COOP_KS_UNREACH: Cooperative KS 1 .2 Unreachable in group dgvpn1 May 7 10:21:32.628: %GDOI - 5 - KS_SEND_UNICAST_REKEY: Sending Unicast Rekey for group dgvpn1 from address 1 .1 with seq # 1 72.16.4 May .2 72.16.4 COOP_KS_UNREACH: Cooperative KS 1 - 3 - 7 10:21:50.329: %GDOI Unreachable in group dgvpn1 3 May 7 10:22:10.330: %GDOI - - COOP_KS_UNREACH: Cooperative KS 1 72.16.4 .2 Unreachable in group dgvpn1 COOP_KS_UNREACH: Cooperative KS 1 .2 3 - 72.16.4 May 7 10:22:30.331: %GDOI - Unreachable in group dgvpn1 message indicates a change in primary KS status: KS 1 COOP_KS_TRANS_TO_PRI The .1 is the 72.16.4 new primary KS; the previous primary KS was KS 1 72.16.4 .2. KS_SEND_UNICAST_REKEY The shows that this KS has sent out a rekey message to the group dgvpn1, with rekey seq# 1. COOP_KS_UNREACH .2. Note that 1 The message indicates that this KS can no longer reach KS 72.16.4 these messages are 20 seconds apart (the policy update timer period). - - KS1 now shows Sec - After transitioning to primary, Sec .3) as Secondary/Alive and KS2 (1 shows Pri 72.16.4 KS as Primary/Dead. #show crypto gdoi ks coop KS1 - Sec <..> of 220 Page 75 © 2018 Cisco Systems, Inc. Cisco Confidential/Proprietary GETVPN Design and Implementation Guide

76 172.16.4. Local Address: 1 Local Priority: 100 Local KS Role: Primary , Local KS Status: Alive <..> Peer Sessions: Session 1: Server handle: 2147483651 172.16.4. 3 Peer Address: Peer Priority: 50 Peer KS Role: Secondary , Peer KS Status: Alive <..> n 2: Sessio Server handle: 2147483656 Peer Address: 2 172.16.4. Peer Priority: 1 Peer KS Role: Primary , Peer KS Status: Dead Antireplay Sequence Number: 11063 <..> 3.7.4.1.1 Role of the New Primary KS When a KS transitions to primary state, it does the following : Sends an announcement message to all KSs. Other active KS learn of the new primary from this  message.  Sends out rekeys with a new TEK to all GMs. 3.7.4.1.2 When the Previous Primary KS Recovers: When the previous primary KS recovers, it sends an announce ment message to all KSs listed in its configuration. Depending on the response, it may or may not become a primary KS. The possible scenarios are: The recovering KS receives an announcement message reply from an existing primary, which has  lower priority. a secondary KS. In this case, there is no preemption, and the recovering KS remains This eliminates unnecessary changes in the system.  The recovering KS receives an announcement message reply from an existing primary, which has higher priority. In this cas e, the recovering KS remains a secondary KS. of Page 76 220 © 2018 Cisco Systems, Inc. Cisco Confidential/Proprietary GETVPN Design and Implementation Guide

77  The recovering KS does not receive a response from a primary KS. In this case, if the recovering KS has the highest priority when compared to other KSs that responded, the recovering KS transitions to primary st ate. For a KS that recovers after a reboot or power cycle, network convergence is an important consideration. If network convergence takes longer than the COOP process, the KS cannot see any messages from other KSs. This emulates a network split (see 3.7.4 .2.3 Network Split and Merge (KS Split)), even though there is no real network split. This might cause unnecessary rekeys to be transmitted after the network converges. It is preferable for network convergence to occur faster than the COOP process at KS in itialization. - Continuing the example in Figure 3 KS recovers, it initially comes up in secondary state. After - 9, when Pri KS - the network converges (COOP process is not completed yet), Pri - KS detects Sec - KS1 as a primary; Pri KS now as Secondary/Alive. - c retains its secondary state. Se KS1 updates Pri - KS1 during this process. - The following message is seen at Sec 2 172.16.4. KS1 has its connectivity with KS - The message COOP_KS_REACH shows that Sec (Pri - KS) restored. KS1# Sec - COOP_KS - 5 7 10:51:30.473: %GDOI May - _REACH: Reachability restored with 172.16.4. 2 in group dgvpn1. Cooperative KS 3.7.4.2 Network Split and Merge Network instability can lead to loss of connectivity between the primary KS and the secondary KSs. This is ontext of the COOP KS. The network split might last for a few seconds, referred to as a network split in the c or through multiple rekey intervals. Depending on the interval, you might see slightly different behaviors. The new primary KS now preserves the existing KEK/TEK during split which miti gates the necessity of rekeying immediately after a split. It also mitigates the necessity of a rekey during a merge that may - immediately follow due to route re convergence. 3.7.4.2.1 Network Split and Merge (KS and GM Split) - stomer purchased MPLS VPN services from two SPs who use Inter AS Consider a scenario where a cu services to join the two regions. If the Inter - AS link fails and there are KSs on both sides of the Inter AS link, - GMs will obtain key material from the KS in their respective partition. ork Split Netw shows that initially KS1 is the primary KS and provides the keys for GMs GM1 and GM2. After a 19 Figure network split, KS2 also becomes a primary KS. Now, GM1 receives its key from KS1, while GM2 receives its key from KS2. of Page 77 220 © 2018 Cisco Systems, Inc. Cisco Confidential/Proprietary GETVPN Design and Implementation Guide

78 Figure 19. Network Split and Merge : KS and GM Split The sequence of events follows: Initially, KS1 and KS2 have connectivity and KS1 (the primary KS) sends the TEK in the rekey 1. messages to GM1 and GM2. 2. A network split occurs that isolates KS1 and GM1 from KS2, KS3, and GM2. etect the loss of connectivity with KS1 and KS2 transitions to primary state. 3. KS2 and KS3 d 4. KS2 issues a rekey to the network and provides a new KEK and TEK to the GMs. The rekey message from KS2 contains the old TEK and the new TEK. GM2 continues to use the old TEK for encryption because it has a lifetime which expires sooner. In the figure above, KS2 only creates a new KEK/TEK if the old one is about to expire. In the case of a unicast rekey, GM2 responds and KS2 eventually times out GM1. In the case of a 5. ey, KS2 is not aware of GM1s state. multicast rek rollover (rekey interval), KS1 issues a new TEK. In the case of a unicast rekey, KS1 - On TEK 6. eventually times out GM2. In case of a multicast rekey, KS1 is not aware of GM2‘s state. compared to GM2. Now, GM1 has a different TEK and KEK as 7. The preceding network split scenario is explained further using CLI outputs from KS1, KS2, GM1, and GM2. 1. Initial state: The following show commands display KS status and roles and TEK and KEK values at the KSs and GMs. Initially, KS1 show s KS2 and KS3 as Secondary/Alive, while KS2 shows KS1 as Primary/Alive. !KS1 KS1# show cry gdoi ks coop <..> 2 172.16.4. Local Address: Local Priority: 175 <..> Local KS Role: Primary , Local KS Status: Alive <..> 172.16.4. KS3 status -- < 3 Peer Address: Peer Priority: 50 of Page 78 220 © 2018 Cisco Systems, Inc. Cisco Confidential/Proprietary GETVPN Design and Implementation Guide

79 Peer KS Role: Secondary , Peer KS Status: Alive <..> KS2 status -- < Peer Address: 172.16.4. 1 Peer Priority: 100 Alive Peer KS Role: Secondary , Peer KS Status: !KS2 KS2# sh cry gdoi ks coop <..> 172.16.4. 1 Local Address: Local Priority: 100 ocal KS Role: Secondary , Local KS Status: Alive L <..> KS3 status < 3 172.16.4. Peer Address: -- Peer Priority: 50 Peer KS Role: Secondary , Peer KS Status: Unknown <..> 2 172.16.4. Peer Address: KS1 status -- < Peer Priority: 175 Peer KS Role: , Peer K S Status: Alive Primary The initial TEK and KEK value at KS1 and KS2 are the same. The following shows only the value at KS1: !KS1 KS1# show cry gdoi ks policy <..> KEK POLICY (transport type: Unicast) spi: 0x8 D35D4A8 241E2A34888E3D1AA6D1F9FA <..> s: ENCAPS_TUNNEL) TEK POLICY (encap 2D45C4E9 - list : 160 access spi : 0x <..> Initially, GM1 and GM2 have the same TEK value, as seen in the active security parameter index (SPI): !GM1 of Page 79 220 © 2018 Cisco Systems, Inc. Cisco Confidential/Proprietary GETVPN Design and Implementation Guide

80 GM1# show cry ipsec sa <..> inbound esp sas: spi: 0x 2D45C4E9 (759547113) Status: ACTIVE > <.. outbound esp sas: 2D45C4E9 (759547113) spi: 0x Status: ACTIVE !GM2 show cry ipsec sa GM2# <..> inbound esp sas: (759547113) 9 2D45C4E spi: 0x Status: ACTIVE <..> outbound esp sas: spi: 0x2D45C4E9(759547113) Status: ACTIVE Initially, both GM1 and GM2 have the same KEK:!GM1 show cry gdoi gm rekey GM1# <..> Rekey (KEK) SA information: src dst conn - id my - cookie his - cookie 13039 1 192.168 8D35D4A8 888E3D1A 172.16.4. New : .100.1 --- --- --- Current: --- --- --- --- --- --- Previous: --- !GM2 GM2# gm rekey show cry gdoi of Page 80 220 © 2018 Cisco Systems, Inc. Cisco Confidential/Proprietary GETVPN Design and Implementation Guide

81 <..> Rekey (KEK) SA information: dst src - id my - cookie his - cookie conn New : 192 .1 68 .1.1 172.16.4. 1 13638 888E3D1A 8D35D4A8 Current: --- --- --- --- --- Previous: --- --- --- --- --- 2. The network split occurs. The following CLI snippets are from th e CLI of the KSs and GMs, showing KS statuses. The TEK and KEK values at the GMs are also compared. At the network split, KS2 becomes the new primary. Here are the log messages from KS2: !message to indicate change in primary GDOI 8 09:39:17.960: % May 1 in group 172.16.4. KS OP_KS_TRANS_TO_PRI: CO - 5 - dgvpn1 transitioned to Primary (Previous Primary = 2) 172.16.4. !message indicates that when this KS transitions to primary, it sends out a rekey with new key values to known GMs May 8 09:39:17.992: % GDOI - 5 - KS_SEN D_UNICAST_REKEY: Sending Unicast Rekey for group dgvpn1 from address 172.16.4. 1 with seq # 1 !message indicating that KS2 can‟t reach KS1 Cooperative KS - 3 - GDOI 8 09:39:22.960: % COOP_KS_UNREACH: 2 172.16.4. May Unreachable in group dgvpn1 After the split, K S1 shows KS2 and KS3 as dead, and KS2 also shows KS1 as dead. !KS1 KS1# show cry gdoi ks coop <..> 2 Local Address: 172.16.4. Local Priority: 175 Local KS Role: Primary , Local KS Status: Alive <..> Peer Address: 3 < -- 172.16.4. KS3 status Peer Priority: 50 Peer KS Role: Secondary, Peer KS Status: Dead <..> of 220 Page 81 © 2018 Cisco Systems, Inc. Cisco Confidential/Proprietary GETVPN Design and Implementation Guide

82 Peer Address: 172.16.4. 1 < -- KS2 status Peer Priority: 100 Peer KS Role: Secondary , Peer KS Status: Dead !KS2 KS2# show cry gdoi ks coop <..> Local Address: 172.16.4. 1 Local Priority: 100 Local KS Role: P , Local KS Status: Alive rimary <..> KS3 status -- Peer Address: 172.16.4. 3 < Peer Priority: 50 Peer KS Role: Secondary , Peer KS Status: Alive <..> -- KS1 status < 2 172.16.4. Peer Address: Peer Priority: 1 Peer KS Role: Primary , Peer KS Status: Dead After the split, KS2 sends out a rekey. The following log message is from GM2, indicating that GM2 received a rekey from KS2. !message indicates that GM2 (1 92.168 .1.1) received rekey from !KS2( 172.16.4. 1). Rekey sequence number is 1 5 - Received Rekey for group dgvpn May 8 10:39:18.054: % GDOI - GM_RECV_REKEY: to 172.16.4. 1 from 192.168 .1.1 with seq # 1 After the split, KS2 has a different TEK and KEK when compared to KS1. !KS2 KS2# show cry gdoi ks policy <..> KEK POLICY (transport type: Unicast) 08A471AC7A787950926 spi: 0x 78BA208E3 A8BC <..> TEK POLICY (encaps: ENCAPS_TUNNEL) - access 30808D3D : 0x spi : 160 list of Page 82 220 © 2018 Cisco Systems, Inc. Cisco Confidential/Proprietary GETVPN Design and Implementation Guide

83 After the split, GM2 receives a rekey from KS2, so it now has a different TEK when compared to GM1. GM2 should have the old and the new TEK. !GM2 sec sa show cry ip GM2# <..> inbound esp sas: spi: 0x30808D3D(813731133) Status: ACTIVE <..> outbound esp sas: spi: 0x30808D3D(813731133) Status: ACTIVEAfter three rekeys, KS1 eventually times out GM2 (This is only in case of unicast rekey, as used in th is example). The GM2 state at KS1, after the third rekey and its retransmits are attempted, is as follows: !KS1 1 egin | b < check GM2 .1.1 92.168 KS1# sh ow cry pto gdoi ks mem ber -- status .1.1 192.168 : Group Member ID Group ID : 61440 Group Name : dgvpn1 Server ID : 172.16.4. 1 Key 3 : Rekeys sent Rekeys retries : 6 : 0 Rekey Acks Rcvd Rekey Acks missed: 2 9 7 the 1st seq#1 was -- < 0 Sent seq num: 8 rekey, & 0 3 are seq#2 & Rcvd seq num: 0 0 0 retransmits seq #4 is the 2nd rekey seq #7 is the 3rd rekey & 9 are retransmits s eq#8 & For this example, rekey was of Page 83 220 © 2018 Cisco Systems, Inc. Cisco Confidential/Proprietary GETVPN Design and Implementation Guide

84 configured 30 sec retrans - mit interval, & 2 retrans - mit count After the third rekey, that is, just before the fourth rekey is sent, KS1 deletes GM2. Similarly, KS2 deletes GM1. ges from KS1 and KS2 indicate that the GM is deleted. The following log messa !From KS1 May 8 11:30:28.026: % GDOI - 4 - GM_DELETE: GM 192.168 .1.1 deleted from group dgvpn1. !From KS2 GDOI .100.1 deleted from group dgvpn1.3.7.4.2.2 192.168 GM GM_DELETE: - 4 - 8 11:30:08.157: % May Merge Network If the network split is long enough, GM1 and GM2 will have a different KEK and TEK. So, when a merge occurs, the primary KS must ensure that the GMs understand the new rekey information. Therefore, the . 20 ncrypted with both KEKs, as shown in Figure primary KS sends out rekey information that is e Network Split and Merge: KS and GM Merge Figure 20. The sequence of events follows: Before the merge, GM1 and GM2 have a different KEK, and might have a different TEK. 1. it. If the split lasted longer than the TEK rollover, (This depends on the duration of the network spl the GMs will have different TEKs.) 2. After the merge, KS1 and KS2 have their connectivity restored. KS2 discovers KS1 is in primary state and has higher priority, so KS2 demotes itself to secondary state. 3. KS1 now issues a rekey, encrypted using the existing KEK. KS2 issues a rekey with its old KEK and informs all GMs to now use the same KEK as KS1. Both the rekeys from KS1 and KS2 also include the multiple TEKs. me KEK as GM1. 4. After the rekey, GM2 reverts to using the sa After the rekey, GM1 and GM2 have both TEK values. They continue to use the TEK that has the 5. shortest remaining lifetime. of 220 Page 84 © 2018 Cisco Systems, Inc. Cisco Confidential/Proprietary GETVPN Design and Implementation Guide

85 This network merge scenario is explained further using CLI outputs from KS1, KS2, GM1, and GM2. ! messages from KS1 May 8 11:36:38.066: % GDOI - 5 - COOP_KS_REACH: Reachability restored with Cooperative KS 172.16.4. 3 in group dgvpn1. : Sending Unicast Rekey for KS_SEND_UNICAST_REKEY May - 8 11:36:48.066: % GDOI - 5 172.16.4. 2 with seq # 11 group dgvpn1 from address ! messages from K S2 8 10:36:38.213: % GDOI - 5 - COOP_KS_REACH : Reachability restored with May 172.16.4. 2 in group dgvpn1. Cooperative KS COOP_KS_TRANS_TO_PRI - 5 GDOI 8 10:36:48.033: % May - 2 in group 172.16.4. : KS dgvpn1 transitioned to Primary (Previous Primary = 172.16.4. 1) : Sending Unicast Rekey for y 5 - 8 10:36:48.065: % GDOI Ma KS_SEND_UNICAST_REKEY - group dgvpn1 from address 172.16.4. 1 with seq # 11 KS1 shows KS2 as Secondary/Alive, while KS2 shows KS1 as Primary/Alive. CLI output from KS2 follows: !KS2 KS2# show cry gdoi ks co op <..> Local Address: 172.16.4. 1 Local Priority: 100 Local KS Role: Secondary , Local KS Status: Alive <..> 172.16.4. Peer Address: 3 < -- KS3 status Peer Priority: 50 Peer KS Role: Secondary , Peer KS Status: Unknown <..> 2 < -- Peer Address: KS1 s tatus 172.16.4. Peer Priority: 175 Peer KS Role: Primary , Peer KS Status: Alive of Page 85 220 © 2018 Cisco Systems, Inc. Cisco Confidential/Proprietary GETVPN Design and Implementation Guide

86 The TEK and KEK values at KS1 are shown. Similar keys can be seen at KS2 (not shown here) Note that KS1 has two sets of keys: one under server 172.16.4. 2 and another under server 172.16 .4. 1 (KS2). The KEK value is the same for both sets, but they have different TEK values. !KS1 KS1# show cry gdoi ks policy For group dgvpn1 (handle: 2147483650) server 2 (handle: 172.16.4. 2147483650): # of teks: 1 Seq num: 11 KEK POLICY (transport type: Unicast) spi: 0x 8D35D4A8 241E2A34888E3D1AA6D1F9FA <..> TEK POLICY (encaps: ENCAPS_TUNNEL) 5B35AD05 : 0x spi - : 160 list access <..> For group dgvpn1 (handle: 2147483650) server 172.16.4. 1 (handle: 2147483653): # of teks: 1 Seq num: 0 KEK POLICY (transpor t type: Unicast) spi: 0x 41E2A34888E3D1AA6D1F9FA 8D35D4A82 <..> TEK POLICY (encaps: ENCAPS_TUNNEL) access spi : 0x 8383AE97 : 160 - list <..> Now we look at GM states. After the merge, both KSs sent out rekeys. Log messages from GM1 and GM2 GMs received rekeys from each KS. indicate that both GM1 ! !rekey received from KS1 ( 2) 172.16.4. - 8 11:36:48.120: %GDOI May GM_RECV_REKEY: Received Rekey for group dgvpn - 5 of Page 86 220 © 2018 Cisco Systems, Inc. Cisco Confidential/Proprietary GETVPN Design and Implementation Guide

87 172.16.4. from 192.168 2 to .100.1 with seq # 11 ! GM2 1) 172.16.4. !rekey received from KS2 ( - 5 GM_RECV_REKEY: Received Rekey for group dgvpn - 6:48.131: %GDOI May 8 11:3 from .1.1 with seq # 11 192.168 1 to 172.16.4. 2) 172.16.4. !rekey received from KS1 ( - - GM_RECV_REKEY: Received Rekey for group dgvpn 5 May 8 11:36:48.211: %GDOI h seq # 11 .1.1 wit 192.168 2 to 172.16.4. from Each GM now has both TEKs and uses the TEK with the shortest remaining lifetime. !GM1 GM1# show cry ipsec sa <..> inbound esp sas: spi: 0x 5B35AD05 (1530244357) Status: ACTIVE aes esp sha - hmac , Status: ACTIVE - spi: 0x 8383AE97 (2206445207) transform: esp - <..> outbound esp sas: spi: 0x (1530244357) 5B35AD05 Status: ACTIVE (2206445207) 8383AE97 spi: 0x Status: ACTIVE !GM2 GM2#show cry ipsec sa <..> current outbound spi: 0x8383AE97(2206445207) inbound esp sas: (2206445207) Status: 8383AE97 spi: 0x ACTIVE of Page 87 220 © 2018 Cisco Systems, Inc. Cisco Confidential/Proprietary GETVPN Design and Implementation Guide

88 5B35AD05 spi: 0x (1530244357) Status: ACTIVE <..> spi: 0x 8383AE97 (2206445207) Status: ACTIVE spi: 0x 5B35AD05 (1530244357) Status: ACTIVE To summarize: During this kind of network split, GMs have connectivity to the KSs in their respective but do not have connectivity across partitions. After the network split is resolved, the primary KS partition, sends out multiple rekeys, each encrypted using one of the different KEKs, so that all GMs understand this t of keys. rekey information and synchronize to the same se Split and Merge (KS Split) 3.7.4.2.3 Network A network split can occur so that only the primary KS is isolated from rest of the network. When KS2 does not receive any update messages from KS1, KS2 takes over as the primary role and sends out a rekey to the GMs with a new KEK and TEK. As shown in Figure 21 , in this scenario, rekeys sent by the isolated primary KS are not received by any rekeys all GMs. GMs, and eventually time out on all GMs. KS2 assumes the responsibility of primary KS and register with KS2. If an - y GMs fail to receive the rekey, they re Network Split and Merge: Only KS Split Figure 21. This scenario is almost the same as that described in 3.7.4.1 ―KS Failure.‖ The main difference in this become primary KSs, but that rekeys from KS1 never scenario is that during the split, KS1 and KS2 both makes it to any GM. When the network merge occurs, KS2 sees another higher priority KS, and so rolls back to secondary state. 3.7.4.2.4 Network Split and Merge (GM Split, KSs Connected) - In cases that empl to - KS backup link, a network split may occur such that GMs have reachability to oy KS the KS in their partition, but KSs retain full connectivity to each other. In this case, the GM that is unable to register with the reach the primary KS will not be able to receive a rekey - message and will be forced to re secondary KS. The KS will still synchronize their database such that the GM will continue to receive a h consistent set of KEK and TEK. This example highlights the importance of providing an alternative pat between the KS in order to maintain the integrity and consistency of the GM database and key sets. 22 Figure shows a network split, in which the KSs have full connectivity and are able to exchange state information. However, GM2 is unable to reach the pr imary KS (KS1). of Page 88 220 © 2018 Cisco Systems, Inc. Cisco Confidential/Proprietary GETVPN Design and Implementation Guide

89 Figure 22. Network Split & Merge: only GM split If GM2 is configured with both KSs in its configuration, it will eventually re - register with KS2. KS2 will be able icast rekey), but GM2 to inform KS1 about GM2‘s state. KS1 will attempt to issue rekey to GM2 (in case of un registering with KS2. will not receive any rekey and will always end up re - In summary, if KSs have complete connectivity during a network split, there might be some GMs that will not erval of the split. If those GMs have all KSs configured, be able to receive rekey information during the int - they will be able to re register with a secondary KS and obtain valid key information. Rekey messages (all control plane traffic) could also traverse the backup link between the KS such Note: receive rekey messages despite the core network partition. that all GM 3.8 Designing Around MTU Issues Because of additional IPsec overhead added to each packet, MTU related issues are very common in IPsec ideration. If MTU value is not carefully deployments, and MTU size becomes a very important design cons selected by either predefining the MTU value on the end hosts or by dynamically setting it using PMTU discovery, the network performance will be impacted because of fragmentation and reassembly. In the worst case, t he user applications will not work because network devices might not be able to handle the large bit setting. Some of the scenarios which can - packets and are unable to fragment them because of the df GETVPN nd applicable mitigation techniques are environment a GETVPN adversely affect traffic in a discussed below. LAN MTU of 1500 – WAN MTU 44xx (MPLS) - In this scenario, even after adding the 50 60 byte overhead, MTU size is much less than the MTU of the GETVPN traffic in any shape o WAN. The MTU does not affect r form. LAN MTU of 1500 WAN MTU 1500 – In this scenario, when IPsec overhead is added to the maximum packet size the LAN can handle (i.e. 1500 bytes) the resulting packet size becomes greater than the MTU of the WAN. educe the MTU size to a value that the WAN infrastructure can actually The following techniques could help r handle. Manually setting a lower MTU on the hosts By manually setting the host MTU to 1400 bytes, IP packets coming in on the LAN segment will always have 100 extra bytes for encryption overhead. This is the easiest solution to the MTU issues but is harder to deploy because the MTU needs to be tweaked on all the hosts. TCP Traffic of Page 89 220 © 2018 Cisco Systems, Inc. Cisco Confidential/Proprietary GETVPN Design and Implementation Guide

90 Configure ip tcp adjst - mss 1360 on GM LAN interface. This command will ensure that resulting IP packet on th e LAN segment is less than 1400 bytes thereby providing 100 bytes for any overhead. If the maximum MTU is lowered by other links in the core (e.g. some other type of tunneling such as GRE is used in the - his value only affects TCP traffic and has no bearing on core), the adjust mss value can be lowered further. T the UDP traffic. 3.8.1 Hosts Compliant with PMTU Discovery For non - TCP traffic, for a 1500 packet with DF bit set, the GM drops the packet and send ICMP message the MTU. If sender and the application is PMTU compliant, this will result back to sender notifying it to adjust in a packet size which can successfully be handled by WAN. For example, if a GM receives a 1500 byte IP packet with the df bit set and encryption overhead is 60 bytes, GM will noti fy the sender to reduce the MTU - size to 1440 bytes. Sender will comply with the request and the resulting WAN packets will be exactly 1500 bytes. If the maximum MTU value in the core is lower than 1500 bytes because of additional overheads, on the WAN inte rface of the GM set the ip mtu . This will reduce the packet size to what the core can actually handle. For example, if the MTU on a certain link in the core can only be 1400 bytes, set ip mtu 1400 on the WAN interface of GM. When a 1500 byte packet comes in on the LAN - segment with df bit set and the encryption overhead is 60 bytes, the GM will drop the packet and notify the sender to reduce the MTU to 1340 (ip MTU value configured minus the IPsec overhead). Note: GETVPN t work in . Refer to CSCsq23600 for more details End to end PMTU does no 3.8.2 Hosts Not Compliant with PMTU Discovery In some cases, end host or the application running on the end host might not be fully compliant with PMTU discovery. This means the host/application does not reduce the packet size as directed. Additionally, in some cases intermediate routers or firewalls might also drop ICMP messages sent from the GM to the host. If this traffic is TCP based, tcp adjust TCP mss will mitigate the problem. If the traffic is not - based, as a last resort df configuration global bit clear in - bit can be cleared on the GM using crypto ipsec df - - bit and packet will be fragmented. Both the IP fragments will then mode. This will result in clearing of the df be encrypted. The remote GM will be responsible for decryption while the end host will be responsible for IP reassembly. packet In IOS routers, fragmentation is handled in the CEF path therefore the CPU load does not increase as much due to fragmentation. Reassembly on CPU the other ha nd is handled in the process path and results in a major impact. Look ahead fragmentation must be turned on by using crypto ipsec fragmentation - before encryption. - 3. 9 VRF - Aware GETVPN solution. It must be noted that In certain scenarios, it might be desirable to deploy VRFs in GETV PN GETVPN GM is VRF aware but the GETVPN KS is not. The VRF aware GM feature facilitates the separation of control traffic (registration and rekey) from data plane traffic. This is facilitated by the ability of the GMs to ro ute control traffic (registration & rekeys) through a VRF, which is different from the data traffic. and the policies downloaded are applied in a and rekeys are routed through one VRF Basically registration is supported on data plane. lite VRF . Note that only VRF different forwarding of Page 90 220 © 2018 Cisco Systems, Inc. Cisco Confidential/Proprietary GETVPN Design and Implementation Guide

91 Consider the following deployment: Figure 23. Aware GM - VRF F b l e u R V K S S / I P P M L n c h G M B r a F n e e r V R g interface to apply the crypto map - Each VRF will require a unique WAN interface/sub - GET 1. Crypto map applied to each VRF will require reference to a unique VPN group ID crypto gdoi group blue identity number 101 .1.1 172.16 server address ipv4 client registration interface Serial1/0/0 ! crypto gdoi group green identity number 102 .1.1 7 2.1 server address ipv4 1 7 ! crypto map blue 10 gdoi ue set group bl ! crypto map green 10 gdoi set group green ! interface serial0/0/0:101 description WAN interface for VRF blue ip vrf forwarding blue ip address 172.19.1.2 255.255.0.0 crypto map blue ! of Page 91 220 © 2018 Cisco Systems, Inc. Cisco Confidential/Proprietary GETVPN Design and Implementation Guide

92 interface Serial0/0/0:1.102 description WAN interface for VRF green ip vrf forwarding green ip address 172.20.1.2 255.255.0.0 crypto map green ! interface Serial1/0/0 getvpn control traffic interface description ip address 172.18.1.2 255.255.0.0 ! all the GM VRF subinterfaces to connect to It is possible to cause a set of KS to serve all VRFs by allowing a shared interface on the KS. Special security considerations should be taken for such a deployment. Specifically, the KS should use GM authorization and special care must be taken to prevent route leaking. KE identity endpoints for all GMs must be routable in a shared routing domain accessible The I to the KSs. However, the GM IKE identities bound to specific VRFs should not be routable in the other VRFs. gnated route partition specifically for the GDOI The best practice is to configure the KS set to use a desi management and control plane (for example, network operations center (NOC) routing segment). GM IKE identities can be advertised to the NOC routing segment so that the KS can reach all GM VRF subinterfaces. Meanwhile, the GM IKE identity addresses associated with VRFs are not advertised to other GM VRF routing segments. In fact, the GM IKE identity addresses should be blocked via an ACL on the adjacent PE. This method of route partitioning is commonly used by MPLS VPN providers when managing CE on behalf of a customer. VRF_Lite and Route Leaking lite in data path. VRF lite means that all the traffic traversing in the particular - - GETVPN GM requires VRF VRF - lite does not cover route leaking. If route VRF should confide to the same VRF after route lookup. leaking is configured on the GM, packets will be sent out in clear text from the crypto map applied interface. - Aware GET - In VRF GM Group Member, all the route lookups for traffic coming in from interface VRF RED Ethernet0/1 and routed out through the interface GigabitEthernet0/2.1 will happen in Gigabit . For SAs will be installed in the VRF RED. Any traffic coming in the VRF RED and IPS this case, GETVPN ec routed out the interface GigabitEthernet0/2.1 will be clas - map sified by the GETVPN crypto map getvpn policies. of Page 92 220 © 2018 Cisco Systems, Inc. Cisco Confidential/Proprietary GETVPN Design and Implementation Guide

93 lite data path - Topology of VRF Figure 24. - GM: Example configuration of GET ip vrf RED rd 1:100 route - target export 1:100 target import 1:100 route - ! ip vrf management rd 1:299 target export 1:299 - route target import 1:299 - route GETVPN RED - crypto gdoi group identity number 1357924680 server address ipv4 10.32.178.56 server address ipv4 10.32.178.23 client registration interface GigabitEthernet0/2.2 crypto map GETVPN - map 1 gdoi set group RED - GETVPN acl - encryption - match address no interface GigabitEthernet0/1 of Page 93 220 © 2018 Cisco Systems, Inc. Cisco Confidential/Proprietary GETVPN Design and Implementation Guide

94 ip address 10.32.178.6 255.255.255.252 ip vrf forwarding RED ... interface GigabitEthernet0/2 no ip address ... interface GigabitEthernet0/2.1 ace for data traffic description outside interf encapsulation dot1Q 1033 ip vrf forwarding RED ip address 10.32.178.9 255.255.255.252 - map GETVPN crypto map interface GigabitEthernet0/2.2 control traffic interface GETVPN description encapsulation dot1Q 1066 ip vrf forwarding ma nagement ip address 10.32.178.13 255.255.255.252 ... If route leaking is required to make the traffic flow from an interface participating in global routing to another interface with VRF forwarding or vice following is required: the versa, - king on the router behind the GM and make sure Enable route lea incoming traffic goes into the same the VRF in the GM and routed out of the same VRF interface where crypto map is applied. of Page 94 220 © 2018 Cisco Systems, Inc. Cisco Confidential/Proprietary GETVPN Design and Implementation Guide

95 Topology with route leaking Figure 25. ration in G router behind the GM: Example route leaking configu interface GigabitEthernet0/0 ip address 10.32.176.2 255.255.255.252 interface GigabitEthernet0/1 ip vrf forwarding RED ip address 10.32.178.5 255.255.255.252 VRF network ! Packet routed from global routing table destined for RED 10.32.178.0/25, ! inject the traffic into RED VRF path ip route 10.32.178.0 255.255.255.0 GigabitEthernet0/1 ! Return packet routed from RED VRF, destined for a network in global routing table, ! inject the traffic into global routing pa th ip route vrf RED 0.0.0.0 0.0.0.0 10.32.176.1 global The above configuration in router behind the GM receives traffic from an interface (Gi0/0) participating in global routing to another interface (Gi0/1) with RED VRF forwarding. This way GET_GM router receives the traffic out encrypted in the same RED VRF traffic from RED VRF forwarding interface Gi0/1 and sends the forwarding interface Gi0/2.1 where crypto map is applied. 3. Aware GETVPN Deployment Scenarios - .1 VRF 9 of Page 95 220 © 2018 Cisco Systems, Inc. Cisco Confidential/Proprietary GETVPN Design and Implementation Guide

96 9 and crypto maps GDOI groups/policies 3. .1.1 Shared - interfaces, each interface/sub - interface is in a The same crypto map is applied to multiple interfaces/sub different VRF context or the same VRF context. Key servers are accessible through a different VRF or global VRF. This can be address ed by configuring a group member with a specified registration interface. The corresponding gdoi crypto map will be applied to all the data plane interface/sub interfaces. In such - case, there is only one group member registration for all the crypto maps ap plied to different interfaces/sub - interfaces. After successful registration, policies are downloaded to where the crypto maps are applied. So in this case, there is one single registration and one single rekey would be received. Figure 26 illustrates this scenario: Figure 26. Shared crypto map deployment n p v - a i o d g 0 1 d e r a h s p m o t p y r c E C g p d s e t e r o u s h a r r v f c r i p t o m a p s h a r e d - v p n 1 0 g d o y v p i n g t g d o r o o u p s h a r p y e d - r c s e t g r o u p s h a r e d a s c i l o p d e r y h p u o r g f r v s k n o i t a r t s i g e R - I O D G y e k e R t s a c i t l u M / t s a c i n U c o n r f v P E Use Case: Enterprise VPN that requires encryp tion of traffic regardless of the virtual partition. The same s policy can be used on all partitions. Separation i done via routing of traffic or access control lists. For routed separation, the PE is required to use distinct VRF‘s per customer partition. For access control separation, the PE may use a shared VRF. Advantage: oup policy for all partitions. Configuration and distribution of one gr ) must be universally applicable to each partition. ies Policy distributed (permits and den Disadvantage: 9 .1.2 Different groups/policies with different crypto maps sharing same KS 3. signed to separate groups are applied to different interfaces, each In this scenario, different crypto maps as interface is in a different VRF context or the 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 configured with the same KS and same registration interface/sub interface. So for every group there is one single registration and also one rekey received. All these group members would be using t he same IKE SA which is established between the CE and the Key server. Figure 27 illustrates this scenario. Page 96 of 220 © 2018 Cisco Systems, Inc. Cisco Confidential/Proprietary GETVPN Design and Implementation Guide

97 Figure 27. Different crypto map sharing the same KS deployment c r y p t o m a p b p u e - v p n 5 i p s e c - i s a k m l r d d a _ p i < _ > 1 s s e s e t p e e r C E b c r y p t o m a p e l u - v p n 1 0 g d o i g d o i p t c y r o g r o u p b l n p v - e u l u e s e t g r o u p b i g r o u p b c y l o p e u l r c d g o t p y o i g r o u p g r e e n - v p n v r f g o p n e e r c p u i l o r g y n c r p m k a s i - c e s p i 5 y p v - n e e r g p a m o t p < a s e t p e e r i p > 2 _ s s e r d d _ v p n 1 0 g d o i c r y p t o m a p g r e e n - n e r g p u o r g t e s e s r v k f n o i t a r t s i g e R - I O D G y e k e R t s a c i t l u M / t s a c i n U E P Use Case: elective encryption of traffic based on the virtual partition. Most Enterprise VPN that requires s likely, unique policies will be applied. Separation may be maintained by crypto selectors with shared routing infrastructure. Routing separation may be maintained by discrete VRF‘s on t he PE. Management control plane accessible from the enterprise. - to - Configuration and distribution of discrete group policy for all partitions. Application of point Advantage: for all groups. point IPSec SA‘s is properly applied to two interfaces. CE identity is shared Policy and credentials must be configured on the KS for each group. Disadvantage: groups/policies with different crypto maps on different KSs .1.3 Different 9 3. In this deployment, different Group Member crypto maps are applied to differen t interfaces, where each interface is in a different VRF context or same VRF context. All these groups are accessing different Key Server and these Key Servers are accessible through different VRFs or global VRF table. This is addressed p members configured with different KS and same or different registration interfaces. So by having each grou for every group there is one single registration and also one rekey received. Since every registration is with a different Key server, there will be a different IKE established for every registration. Figure 28 SA illustrates this scenario: 220 Page 97 of © 2018 Cisco Systems, Inc. Cisco Confidential/Proprietary GETVPN Design and Implementation Guide

98 Figure 28. Different crypto maps sharing the different KS deployment r y p t o m a p b l u e - c p n 5 i p s e c - i s a k m p v 1 i s e t p e e r < > p _ a d d r e s s _ E C c r y p t o m a p b l u e - v p n 1 0 g d o i r s e t g o u p b l u e i o d g o t b p u o r n p v - e g u l p y r c v r f u r o u p b l e p g o l i c y s e c - i s a k m p r t o m a p g r e e n - v p n 5 i p p c y o y p v - n e e r g p u n r g i o d g o t p r c _ > 2 s e r d d a _ p i < r e e p t e s s e r g p u o r g y c i l o p n e 0 p r t o m a p g r e e n - v p n 1 y g d o i c r s e t g r o u p g e e n 1 s k f r v n o i t a r t s i g e R - I O D O O C P G 2 s k y e k e R t s a c i t l u M / t s a c i n U P E Enterprise VPN that requires selective encryption of traf fic based on the virtual partition. Most Use Case: likely, unique policies will be applied. Separation may be maintained by crypto selectors with shared routing infrastructure. Routing separation may be maintained by discrete VRF‘s on the PE. Management control plane accessible from the enterprise. Advantage: Configuration and distribution of discrete group policy for all partitions. Application of point - - to point IPSec SA‘s is properly applied to two interfaces. CE identity shared for all groups. Policy and credentials must be configured on the KS for each group. Disadvantage: VRF . 2 9 - Aware Software Infrastructure (VASI) Routing 3. Aware VRF - The ASR1000 platform allows the use of crypto maps on Software Infrastructure (VASI) interfaces . The VASI interfaces bind two VRF s together using back - to - back internal interfaces between an ̳Inside VRF‘ (iVRF) and a ̳Front - - Left and VASI - door VRF‘ (fVRF). The VASI are often referred to as VASI Right respective to the iVRF and fVRF. The iVRF connects to the client‘s private L AN environment and routes unencrypted traffic into the VASI - Left in the iVRF where a GETVPN crypto map is applied. The paired VASI - Right receives the GETVPN encrypted packet and implements a second route lookup in the fVRF. The fVRF routes the GET encrypte d packet to the WAN infrastructure. The packets routed through a shared fVRF must have unique IP address ranges for each iVRF such that return packets can be directed to the proper iVRF. GET encrypted packets arriving at an fVRF are routed to the VASI - Righ t interface that is bound to the VASI - Left of the appropriate iVRF. The GETVPN crypto map associated with the VASI Left interface will decrypt the GET packet and route the packet in the iVRF - associated with the client‘s private LAN infrastructure. The us e of VASI interfaces in the ASR allows the operator to collapse the encryption and virtual routing infrastructure into a single platform. The WAN routing methods on the fVRF are decoupled from the encryption methods on the iVRF; therefore, the choice of WA N routing methods is independent of the crypto 29 illustrates the use of VASI with VRF aware GDOI. - lite. Figure restrictions for VRF s are supported on VASI interfaces GDOI crypto map Only Note: Page 98 of 220 © 2018 Cisco Systems, Inc. Cisco Confidential/Proprietary GETVPN Design and Implementation Guide

99 VASI Based VRF aware GDOI on ASR1000 Figure 29. : based VRF aware GDOI/GKM e following is a configuration snippet for VASI Th nterface vasileft1 i .112.255.255.255.255 0.10.10 ip address 1 - Blue VRF vrf forwarding MAP crypto map GETVPN - interface vasiright1 ip address 10 .10 . 20 .113 255.255.255.255 vrf forwar - Core - Blue VRF ding crypto isakmp policy 10 encryption AES group 2 Blue crypto gdoi group identity number 1234 server address ipv4 10.10.12.34 MAP local crypto map GETVPN address GigabitEthernet1/1 - - MAP 10 gdoi - crypto map GETVPN set group Blue of Page 99 220 © 2018 Cisco Systems, Inc. Cisco Confidential/Proprietary GETVPN Design and Implementation Guide

100 1 0 3. PN Support for IPv6 in the Data Plane GETV . The control plane GET VPN supports GDOI protection for IPv6 traffic in the dataplane (GM - to - GM) Currently - continues to use IPv4. The GM needs to be a dual stack device in communication (KS - to - KS and KS - to - GM) order to - plane and ipv4 for control - plane. support ipv6 for data , ISR4k and ASR1k platforms. IPv6 support on ISRG2 platforms GETVPN with IPv6 is supported on ISRG2 is - supported on IOS is enabled from 15.2(3)T release and XE based platforms from XE3.9 S release. Du al stack IPv4/IPv6 support on the crypto interface of the GM is enabled in 15.2(3)T on ISR - G2 and XE3. 10.3 . on IOS - XE platform s The communication between GM and KS includes GDOI registration and rekey . , and this is purely with IPv4 That means: On a KS,  will use IPv4 IKE IPv6 GDOI policy, registration process a hough it is configured with lt a SA.  On a GM , registration and rekey are all using IPv4 process, and ―Key encrypting key (KEK)‖ is still an IPv4 IKE SA. After registration or rekey, the policies downlo aded from key server are IPv6 policies. The traffic encrypting keys (TEK) downloaded are IPv6 keys. The corresponding IPv6 IPSec SAs will be installed . Note: Mixed mode under the same group is not supported. In other words, configur ing both IPv4 and IPv6 either IPv4 OR IPv6 policies for a single group Configuring . is not supported polici es under the same group is supported. By configuring the crypto gdoi group ipv6 plane is in IPv6 and only , it is assumed that the data command d on the KS group configuration. Once a group is configured as ―ipv6‖, ―match address ipv6‖ will be allowe match address using the configuration of the displayed and IP v4 ACL is not allowed anymore. A warning is or vice group from IPv4 to IPv6 GDOI hanging a - removes the versa the configuration will not be accepted. C and recreate s them. policy and GM database corresponding to that group, v6 .1 Verifying GETVPN support for 0 1 3. IP All devices in the same group (including the KS, cooperative KSs, and GMs) must support the The GETVPN for IPv6 in the Data Plane feature before the group's KS can enable the feature. GETVPN we command that the following use on the KS (or primary KS) to check whether all devices feature provides in the network are running versions that support it. of Page 100 220 © 2018 Cisco Systems, Inc. Cisco Confidential/Proprietary GETVPN Design and Implementation Guide

101 crypto Router# show crypto gdoi feature ipv6 - - p ath When this command is executed on the KS (or primary KS), the version of the software on each KS and GM is displayed. The output also displays whether all devices support IPv6 encryption and decryption (and thus can be added to an IPv6 group). displays information only for that GM executed on a GM, When the command . Configuring IPv6 group on the KS 3. 1 0 . 2 Current implementation requires separate GDOI groups for IPv6 and IPv4. There is no support for mixed mode, ans that a group cannot be configured with both IPv6 and IPv4 policies. which me The following configuration is for an IPv6 GDOI group on KS: ! IKE Phase 1 configuration remains unchanged crypto isakmp policy 10 encr aes hash sha256 86400 lifetime authenticat share - ion pre group 14 .1. crypto isakmp key Cisco address 1 72 .1 9 2 cry pto isakmp key Cisco address 172.20.2 . 2 set and profile remains unchanged ! IPSec transform - - aes esp set AES_SHA esp - crypto ipsec transform hmac - sha - crypto ipsec profile IPSEC_PROF_G ETV6 set AES _SHA - set transform IPv6 policy ACL ! list ACL_GETV6_ANY3 - ipv6 access deny icmp fe80::/10 any deny icmp any fe80::/10 permit ipv6 any any “ipv6” keyword to create a GDOI ipv6 group ! - crypto gdoi group ipv6 GETV6 identity number 1111 er local serv rekey retransmit 10 number 2 of Page 101 220 © 2018 Cisco Systems, Inc. Cisco Confidential/Proprietary GETVPN Design and Implementation Guide

102 rekey authentication mypubkey rsa GETKEY rekey transport unicast 172.16.4.2 address ipv4 ! “ipv6” keyword to specify an IPv6 policy ACL sa ipsec 1 profile IPSEC_PROF_GETV6 match address ipv6 ACL_GETV6_AN Y3 3. 1 0 . 3 Configuring IPv6 group on the GM and On the GM, are needed for IP v6 s IP v4 traffic . IPs ec crypto maps do not support separate crypto map mixed mode. The control plane uses IPv4 to register to the KS, download IPv6 policies, download IPv6 TEKs a nd to receive rekeys . When a GM downloads the policy from the KS, it confirms that the policy the next . If not, the policy is rejected, and the GM attempts to register to traffic defines IPv6 list. s it n i KS that support IPv6 crypto maps. For other platforms, the The feature is supported only on those platforms applicable configuration commands are disabled. The following configuration is for a n IPv6 GDOI on GM: ! IKE Phase 1 configuration remains unchanged crypto isakmp policy 10 encr aes hash sha256 l ifetime 86400 - share authentication pre group 14 crypto isakmp key Cisco address 172.16.4.2 crypto isakmp key Cisco address 172.18.5.2 ipv6 group - “ipv6” keyword to create a GDOI ! crypto gdoi group ipv6 GETV6 identity number 1111 172.16.4.2 server address ipv4 172.18.5.2 server address ipv4 ! map gdoi crypto IPv6 Configure crypto map ipv6 CM_GET_V6 10 gdoi set group GET_GRP_V6 220 Page 102 of © 2018 Cisco Systems, Inc. Cisco Confidential/Proprietary GETVPN Design and Implementation Guide

103 match address GM_ACL_V6 v6 GDOI cryptomap on stack - interfaces with dual ! IP int GigabitEthernet0/0 1. . 9 .1 2 255.255.0.0 72 ip address 1 2001:DB8:FFFF::2/64 ipv6 address ipv6 crypto map CM_GET_V6 1 3.1 upport for LISP S GETVPN homing, virtualization, and host/VM mobility for both - The inherent properties of LISP give it support for multi agnostic, Virtual IPv4 and IPv6 address families make it an ideal architecture for crea ting highly efficient, AF - Private Networks (VPNs). Existing IOS encryption support provided by the IPsec and GETVPN features can be used directly (in a ―bolt - on‖ manner) with LISP to build encrypted VPNs.B ecause LISP separates locators and endpoint identifiers, encryption can be added using IPsec or GETVPN by applying the crypto map to Figure either the EID side (LISP0 virtual interface), or to the locator side (RLOC interface(s)), as illustrated in 30 . GETVPN with LISP ‖ on - l t Figure 30. pto Map Application Points Available to ―bo Cry Depending on where the crypto map is applied (as per Figure 1), the resulting configuration details change, crypto LISP solution, With GETVPN+ as does the resultant packet handling and encrypted packet format. is applied to the LISP0 virtual interface. This is the most common architecture and provides the most map , LISP0 flexibility for applying unique security policies within the resultant VPN environment. When applied to occurs first, followed by LISP encapsulation. The packet construction process is GETVPN encryption 31 illustrated in Figure below. of Page 103 220 © 2018 Cisco Systems, Inc. Cisco Confidential/Proprietary GETVPN Design and Implementation Guide

104 results in GETVPN and then LISP LISP with GETVPN applied to LISP0 Figure 31. c rypto map with LISP interfaces, To configure GETVPN interface LISP0 ! nterface LISP0.1 i ip mtu 1456 ipv6 mtu 1436 - 0001 V6 - ipv6 crypto map MAP 0001 - V4 - crypto map MAP interface LISP0.2 ip mtu 1456 ipv6 mtu 1436 - 0002 - ipv6 crypto map MAP V6 crypto map MAP V4 - 0002 - interface LISP0.3 ip mtu 1456 ipv6 mtu 1436 V6 - - 0003 ipv6 crypto map MAP 0003 - V4 - crypto map MAP The LISP process automatically creates each LISP0.x virtual interfaces once an IID is configured. LISP0 should not have a crypto map and thus incurs no encryption. Only the LISP0.x int (default table) erfaces associated with the Departmental VPNs are encrypted - – each with its own policy, and on a per address family basis as well. of Page 104 220 © 2018 Cisco Systems, Inc. Cisco Confidential/Proprietary GETVPN Design and Implementation Guide

105 For more information on LISP deployment details with GETVPN, refer to the resources below - 0/GETVPN.pdf https://www.cisco.com/c/dam/en/us/td/docs/solutions/Enterprise/Data_Center/DCI/5 http://lisp.c isco.com/docs/GETVPN_LISP_Deployment_1.0.pdf http://lisp.cisco.com/lisp_tech.html#CG 3. GDOI Bypass 2 1 GETVPN and control The GETVPN GDOI Bypass feature allows enabling or disabling the GDOI bypass crypto policy traffic exceptions by explicitly configuring the GM local access control list (ACL). - map is applied to an interface, a default crypto policy is installed to allow GDOI When a GDOI crypto protocol traffic (UDP port 848 sourced from any IP addres s and destined to any IP address) to pass through in cleartext . The GETVPN GDOI Bypass feature improves the security of the default GDOI bypass crypto - policy when handling UDP848 traffic in the following ways: Enable and disable the default GDOI bypass cr  a new CLI on the GM client ypto policy through the policy bypass - Hardening the GM‘s default GDOI bypass crypto policy when enabled  By default, GDOI client The GDOI Bypass policy will be installed only on GETVPN protected interfaces. - bypass ed to ensure backward compatibility. policy is enabl - When GDOI bypass is enabled, the following will be seen on the GM: # show crypto gdoi gm acl GM Group Name: GETVPN ACL Downloaded From KS 10.0.0.2: list deny eigrp any any - access - list permit ip any any access ACL Configured Locally: ACL of default GDOI bypass policy: * Ethernet1/0: deny udp host 10.0.0.9 eq 848 any eq 848 vrf RED refer to the For more information on this feature , GDOI Bypass in GETVPN Configuration Guide. . 3 1 GETVPN Routing Awareness 3. The Routing Awareness feature prevents routing black hole by tracking the GETVPN GETVPN GM crypto state and by applying the tracking information to perform bidirectional conditional route filtering on the GM. Th e GETVPN Routing Awareness feature prevents routing black hole by tracking the GETVPN GM crypto state and by applying the tr acking information to perform bidirectional conditional route filtering on the GM. must blackholes. Before a G M The routing plane and crypto plane for GETVPN to avoid be synchronized keys are installe successfully registers to a KS , no security policies or d on the GM; however, the GM may ‖ sa track still advertise the routes of its protected network to other GMs. The command ― client status active - XE Release routing awareness enable - was introduced to . The feature is available since Cisco IOS GETVPN 3.13S. r more information on routing awareness and configuration examples, refer to Fo GETVPN Routing in GETVPN Configuration Guide. Awareness of Page 105 220 © 2018 Cisco Systems, Inc. Cisco Confidential/Proprietary GETVPN Design and Implementation Guide

106 4 3.1 IPsec Inline Tagging for Cisco TrustSec on GETVPN Cisco TrustSec (CTS) architecture secures networks by establishing domains of trusted network devices. ticates with the network, the communication on the links between devices in Once a network device authen the cloud is secured with a combination of encryption, message integrity checks, and replay protection mechanisms. during the authentication phase to classify CTS uses the user and device identification information acquired packets as they enter the network. CTS maintains classification of each packet or frame by tagging it with a security group tag (SGT) on ingress to the network so that it can be identified for applying security a nd other policy criteria along the data path. The tags allow network intermediaries such as switches and firewalls to enforce access control policy based on the classification. GET inline tagging to VPN Support of IPsec Inline Tagging for Cisco TrustSec feature uses VPN The GET carry the SGT information across the private WAN. For information on restrictions, more conceptual information, configuration, and verification examples, go to GET document. VPN Support of IPsec Inline Tagging for Cisco TrustSec GM) or receives When a KS receives a security association (SA) registration request from a group member ( a connection establishment request from a cooperative KS, it checks whether any group SA has SGT inline tagging enabled. If so, all GMs and cooperative KSs must register using GETVPN software version 1.0.5 or e, the registration request or establishment request is rejected, and the KS higher to be accepted. Otherwis generates a syslog message to notify the network administrator. The following e VPN software versioning command on the KS (or primary xample shows how to use the GET ether all the devices in each group support IPsec inline tagging for Cisco TrustSec: KS) to check wh sgt - Device# show crypto gdoi feature cts Group Name: GETVPN Key Server ID Version Feature Supported 10.0.5.2 1.0.5 Yes 10.0.6 .2 1.0.5 Yes 10.0.7.2 1.0.3 No 10.0.8.2 1.0.2 No Group Member ID Version Feature Supported 10.0.1.2 1.0.2 No 10.0.2.5 1.0.3 No 10.0.3.1 1.0.5 Yes 10.0.3.2 1.0.5 Yes You can also enter the above command on a GM (which display the information for the GM but not for the s KS or other GMs). d only those devices mmand on the KS (or primary KS) fin The following example shows how to enter the co VPN network that do not support IPsec inline tagging for Cisco TrustSec: in the GET - Device# show crypto gdoi feature cts sgt | include No of Page 106 220 © 2018 Cisco Systems, Inc. Cisco Confidential/Proprietary GETVPN Design and Implementation Guide

107 10.0.7.2 1.0.3 No 10.0.8.2 1.0.2 No 10.0.1.2 1.0.2 No 10.0.2.5 1.0.3 No The following configuration snippet configures IPsec inline tagging o n a KS: ip access SGT - list extended ACL - permit ip any any exit crypto gdoi group GET - SGT identity number 1 server local sa ipsec 1 tag cts sgt p2 profile gdoi - - match address ipv4 ACL SGT size 100 - replay time window n a o IPsec The following configuration snippet configures inline tagging iguration, there are GM. In this conf two groups: A group wi th GMs that are upgraded to GET VPN version 1.0.5 or higher (and therefore supports CTS SGT inline tagging) and a group with GMs that are not yet upgraded. The upgraded GMs will register to er crypto map sequence number) and with group number 2222 (a higher crypto group number 1111 (a low - upgraded GMs will register only to group number 2222. - map sequence number). Non In this example SGT tagging for traffic is configured between two sites. The permit ip commands add access control entries (ACEs) to the access control list (ACL) that permit communication between the two sites: ip access - list extended ACL_NET_AB permit ip 10.1.0.0 0.0.255.255 10.2.0.0 0.0.255.255 permit ip 10.2.0.0 0.0.255.255 10.1.0.0 0.0.255.255 it ex list extended ACL_ALL - ip access permit ip any any exit crypto gdoi group GET1 identity number 1111 server local rekey authentication mypubkey rsa mykey rekey transport unicast sa ipsec 1 tag cts sgt p2 - profile gdoi ACL_NET_AB match address ipv4 size 100 - replay time window exit exit of Page 107 220 © 2018 Cisco Systems, Inc. Cisco Confidential/Proprietary GETVPN Design and Implementation Guide

108 exit crypto gdoi group GET2 crypto gdoi group GET2 server local rekey authentication mypubkey rsa mykey rekey transport unicast sa ipsec 1 profile gdoi - p2 match address ipv4 ACL_A LL - size 100 replay time window 3. GETVPN Software versioning 15 feature compatibility issues. implemented in GETVPN software to simplify A versioning system has been Major – _version GDOI SW version has three parts , Minor _version , and Mini _version in t he following format: Major_version.Minor_version.Mini_version  devices. Major_version defines compatibility for all GETVPN - KS (cooperative key server) associations and for GM Minor_version defines compatibility for KS - to  - to - GM interoperability. Mini_version tracks feature changes that have no compatibility impact.  Important notes about version compatibility: All GMs and KS must have the same ―major‖ version 1. All GMs must have the same ―minor‖ version 2. must have the same ―minor‖ version s All KS 3. 1 Version 1.0.1 is the b ase - v ersion for releases up to IOS version 4. 15. ( 4 ) M and IOS XE version 15. 2 ( 4 )S or XE 3. 7 KS. Thus, all GMs does not send GM version info to other COOP (1.0.1) - 5. A base - version KS registered to base version KS will be shown up as version ―unknown‖ on t KS - he other COOP - Following is an example matrix that shows KS/GM compatibility based on the version. If the KS and GM are not compatible, the GM registration will not succeed. GM Version 1.1.0 1.0.2 Base (1.0.1) Yes Yes Base (1.0.1) Yes Yes Yes 1 .0.2 Yes Yes Yes 1.1.0 Yes KS Version shows KS/KS compatibility based on the version. If the KSs are not that matrix is an example Following compatible, coop election will not succeed. KS2 Version of Page 108 220 © 2018 Cisco Systems, Inc. Cisco Confidential/Proprietary GETVPN Design and Implementation Guide

109 1.1.0 1.0.2 Base (1.0.1) Yes * No Base (1.0.1) Yes No 1.0.2 Yes Yes * Yes No * 1.1.0 No * KS1 Version * Warning syslog will be printed about version mismatch Commands to : and feature compatibility check GDOI version f 1. GDOI version check o KS - all COOP KS701# sho cry gdoi ks coop Crypto Gdoi Group Name :GET Group handle: 2147483650, Local Key Server handle: 2147483650 Local Address: 10.0.8.1 Local Priority: 10 Local KS Role: Primary , Local KS Status: Alive Local KS version: 1.0.3 ... Pe er Sessions: Session 1: Server handle: 2147483651 Peer Address: 10.0.9.1 Peer Version: 1.0.3 GDOI version check of all GMs from the primary KS 2. KS701#sho cry gdoi ks members Group Member Information : Number of rekeys sent for group GET : 4 GM Version: 1.0.2 Group Member ID : 5.0.0.2 Group ID : 3333 Group Name : GET Key Server ID : 10.0.8.1 ... Group Member ID : 9.0.0.2 GM Version: 1.0.1 Group ID : 333 3 Group Name : GET Key Server ID : 10.0.9.1 ... 3. The following command illustrates feature compatibility with the use of versions show crypto gdoi feature [group ] feature w gdoi feature ? pto KS701# sho cry gdoi - GDOI Management Information Base support mib removal RFC defined delete message to remove GM's policy - gm replace Replace current policy in the rekey message policy - gdoi feature gm removal - KS701# sho w cry pto Group Name: GET Key Server ID Version Feature Supported Yes 1.0.3 10.0.8.1 10.0.9.1 1.0.3 Yes Group Member ID Feature Supported Version 1.0.3 Yes 5.0.0.2 No 1.0.1 9.0.0.2 of Page 109 220 © 2018 Cisco Systems, Inc. Cisco Confidential/Proprietary GETVPN Design and Implementation Guide

110 following table provides information about The - XE . The the different GDOI versions in IOS and IOS IOS/IOS - XE versions listed in the table are the first versions that will have the corresponding GDOI version. Table 3. Mapping between GDOI versions and IOS /IOS - XE releases IOS IOS Release (M&T Train) - Train) /XE16 XE Release (3S/S GDOI Version nknown U N/A 15.2(1)T 1.0.1 15.2(1)T 15.3(1)S/XE 3.8S 1.0.2 15.2(2)T 15.3(1)S2/XE3.8.2S 15.2(1)T – 15.3(1)S / XE3.8S – 1.0.3 1 5.3(1)S/XE 3.8S 15.2(3)T 1.0.4 XE 3.9S - 15.2(4)M 1.0.5 15.3(2)S/XE3.9S N/A 1.0.6 XE 3.9S 15.3(2)T 1.0.7 N/A 15.3(3)S / XE3.10S 1.0.8 15.3(3)S/XE XE 3.10S, XE 3,10.1S 15.3(3)M 1.0.9 15.4(2)T 15.4(2)S/XE 3.12S 1.0.10 15.4(3)M 15.4(3)S/XE 3.13S 1.0.11 N/A N/A 1.0.12 15.5(1)T 15.5(1)S/XE 3.14S (GM only) 1.0.13 15.5(1)T 15.5(1)S/XE 3.14S (KS only) 1.0.14 15.5(2)T 15.5(2)S/XE3.15S 1.0.15 15.5(1)S/XE 3.14S 15.5(1)T 1.0.16 15.5(3)T 15.5(3)S/XE3.16S 1.0.17 N/A Everest 16.5 1.0.18 Ev 15.5(3)S/XE 3.16S erest 16.5 15.5(3)T , 1.0.19 N/A 16.7.1 Fuji the following For detailed information about the features supported for GDOI version s , please refer to these documents: Cisco Group Encrypted Transport VPN Configuration Guide, Cisco IOS Release 15M&T p Encrypted Transport VPN Configuration Guide, Cisco IOS XE Fuji 16.8.x Cisco Grou of Page 110 220 © 2018 Cisco Systems, Inc. Cisco Confidential/Proprietary GETVPN Design and Implementation Guide

111 16 G Replacement 3. M Removal and Policy ; it also al of unwant facilitates GETVPN network easy remov provides a rekey This feature ed GMs from the bsolete SAs . This feature is supported from 15.2(1)T in IOS and method to install new SAs and remove o IOS - XE 3.8 in IOS XE. 15.3(1)S or 3. 6 .1 GM Removal 1 an unwanted GM from a group it was required to complete the Prior to the GM removal feature, to delete following steps : Revoke the 1. hase - 1 credential s (for example, the preshared key or one or more PKI certificates). P 2. Clear the TEK and KEK database on all K ey S ervers . 3. to force each GM to re - register. Clear the TEK and KEK database on each GM individually , clearing - The third step is time there are many Group Members . In addition consuming whe an entire group n manually would cause a network disruption. This feature automates this process by introducing a command that is enter ed on the primary KS to create a new set of TEK and KEK keys and forc e each GM to re - register . Below are the steps to remove an unwanted GM from the group: Revoke IKE Phase - 1 credentials of unwanted GM from all the KSs 1. m delete a send Execute the following command on the primary KS. This will g to all e sa s e 2. secondary KS and G Ms - clear cry gdoi [group ] ks members [now] 3. All KS s delete old TEK/KEK/GM database and install new TEK/KEK 4. All GMs cleanup TEK/KEKs individually and re - register 5. KS will only accept GM registration base d s, thereby blocking t on new IKE credential he unwanted GM from registering with any of the KSs in the group . 3. 16 .1.1 GM Removal with Transient IPsec SAs With the use of transient IP sec SAs, we can avoid disruption in the network as traffic continues to be encrypted and decrypted using the transien t IPsec SA until its lifetime expires. Following steps outline this method of GM removal process:  p hase 1 credentials of unwanted GM from all the KSs Revoke the IKE  clear command on the primary KS Issue the following - Primary bers gdoi ks mem pto KS701#clear cry % This GM Removal message will shorten all GMs' key lifetimes and cause them - to re - register before keys expiry. Are you sure you want to proceed? [yes/no]: yes Sending GM - Removal message to group GET... s : message generate this syslog  The GM will - - 28 08:37:03.103: %GDOI - 4 GM_RECV_DELETE: GM received delete *Jan msg from KS in group GET. TEKs lifetime are reduced and re - registration will start before SA expiry s ely and reduce old TEK lifetime using the following fomula GM delete KEK immediat  (TEK_RLT, MAX(90s, MIN(5%(TEK_CLT), 3600s)) TEK_SLT = MIN TEK_SLT: shortened lifetime; TEK_RLT: Remaining LIfeTime; TEK_CLT: Configured L feTime i revoked GM - will re register to get new TEK/KEK by using the conventional re s except the GM  All - tter applied. registration timer with the ji of Page 111 220 © 2018 Cisco Systems, Inc. Cisco Confidential/Proprietary GETVPN Design and Implementation Guide

112 No network disruption is expected by using transient IPSEC SAs  as traffic continues to flow .1. GM Removal with Immediate IPsec SA Deletion 16 3. 2 This method of GM removal is used to force GMs to delete old TEKs and KEKs immediately (without using register. However, this can cause a disruption to the data plane, so this method should transient SAs) and re - Following if there are important security concerns that require removal of a GM immediately . be used only moval process: steps outline this method of GM re  Phase - 1 credentials of unwanted GM from all the KSs Revoke the IKE  Issue the following clear command on the primary KS - Primary KS701#clear crypto gdoi ks members now - Removal immediate message will cleanup all GMs downloaded polici es % This GM - register. % This will cause all GMs to re Are you sure you want to proceed? [yes/no]: yes - Removal message to group GET... Sending GM  The above command triggers the GMs to do the following: o all TEKs/KEK/policy immediately Delete o to fail - open mode u nless fail - close is explicitly configured o GMs g r GM s except the revoked GM will o e - register successfully within a randomly chosen All period MIN(TEK_RLT, MIN(2%(TEK_CLT), 3600s)) generate this syslog  GM s will The message : *Jan 28 08:27:05.627: %GDOI - 4 - GM_RECV_DEL ETE_IMMEDIATE: GM receive REMOVAL - NOW in group GET to cleanup downloaded policy now. Re - registration will start in a randomly chosen period of 34 sec 3. 16 .1.3 Limitations of GM Removal rejected . The command is KS primary the can only be sent from e g The d when executed on a a elete m es s secondary KS ollowing message: with the f - Secondary KS702#clear crypto gdoi ks members ERROR for group GET: can only execute this command on Primary KS the All and GMs should be upgraded to a supported version for this feat ure to work. Else, KS/GMs will KSs ignore delete - msg and continue to use old SAs result ing in traffic drop . The following warning message is displayed in case some devices do not support this feature. KS701#clear cry pto gdoi ks members WARNING for group GET: s ome devices cannot support GM - REMOVAL and can cause network disruption. Please check 'show crypto gdoi feature'. Are you sure you want to proceed ? [yes/no]: no devices which check feature using the following command on the pr : imary KS e th support It is possible to pto cry - KS701# sho w Primary gdoi feature gm - removal Group Name: GET Version Key Server ID Feature Supported 10.0.8.1 1.0.3 Yes Yes 10.0.9.1 1.0.3 Feature Supported Member ID Version Group 5.0.0.2 Yes 1.0.3 9.0.0.2 No 1.0.1 Rekey and Policy Replacement .2 Triggered 6 3.1 provides a mechanism of triggering rekeys to remove old/obsolet This feature e KEK and TEK while installing new ones after a policy change. The reson for this feature is to streamline the rekey process by eliminating 220 Page 112 of © 2018 Cisco Systems, Inc. Cisco Confidential/Proprietary GETVPN Design and Implementation Guide

113 the inconsistencies with the old inconsistent behavior in the old rekey method. Following table shows rekeying metho d: Table 4. Inconsistencies with the old rekey method Policy Changes Rekey Sent Rekey Behavior After Policy Changes Immediately ? TEK: SA lifetime No The old SA remains active until its lifetime expires. The new lifetime will be effective after the next schedu led rekey. TEK: IPSEC transform The SA of the old transform set remains active until its lifetime expires. Yes set Yes The SA of the old profile remains active until its lifetime expires. TEK: IPSEC profile Yes Outbound packet classification immediately uses the new access control TEK: Matching ACL the old SAs remain in the SA database list (ACL) , however . he old SA without counter replay remains active until its lifetime Yes T TEK: Enable replay counter expires. TEK: Change replay No The SA with a new replay counter is sent out in the next scheduled counter v alue rekey. T he old SA with counter replay enabled remains active until its lifetime TEK: Disable replay Yes expires. counter he old SA with TBAR disabled T Yes TEK: Enable TBAR remains active until its lifetime expires. TEK: Change TBAR No The SA with a new TBAR window will be sent out in the next scheduled rekey. window Yes T he old SA with TBAR enabled remains active until its lifetime expires. TEK: Disable TBAR TEK: Enable receive - Yes Receive - only mode is activated right after the rekey. only TEK: Disable receive - Yes Receive - only mode is deactivated right after the rekey. only The change is applied with the next rekey. No KEK: SA lifetime Yes The change is applied immediately. KEK: Change authe ntication key The change is applied immediately. Yes KEK: Change crypto algorithm rekey. When a policy change is With this feature, policy changes alone will no longer trigger a n immediate strator exit from global configuration mode), a syslog message appears on the made (and the admini s primary KS indicating that the policy has changed and a rekey is needed. This feature provides a new command that can then be entered on the primary KS to send a rekey. The f oll owing example illustrates this feature: KS701 #conf t Primary - Enter configuration commands, one per line. End with CNTL/Z. (config)#crypto gdoi group GET KS701 - Primary KS701(config - Primary group)#server local - gdoi - of Page 113 220 © 2018 Cisco Systems, Inc. Cisco Confidential/Proprietary GETVPN Design and Implementation Guide

114 Primary - - local - server)#sa ipsec 1 KS701(gdoi 1 - p Primary - KS701(gdoi - sa - ipsec)#no profile gdoi ipsec)#profile gdoi p2 - KS701(gdoi - sa - Primary - <= changing the ipsec profile ipsec)#end sa - KS701(gdoi - KS701# - Primary - 5 *Jan 28 09:15:15.527: %SYS - CONFIG_I: Configured from console by console 7: %GDOI - 5 - POLICY_CHANGE: GDOI group GET policy has changed. *Jan 28 09:15:15.52 Use 'crypto gdoi ks rekey' to send a rekey, or the changes will be send in the next scheduled rekey Primary - KS701#crypto gdoi ks rekey - ng Unicast Rekey *Jan 28 09:17:44.363: %GDOI - 5 KS_SEND_UNICAST_REKEY: Sendi with policy replace for group GET from address 10.0.8.1 with seq # 2 - Once the triggered rekey command is issued on the primary KS, GMs install new SAs and reduce the old SA lifetime using the following formula: 0s, MIN(5%(TEK_CLT), 3600s))) TEK_SLT = MIN(TEK_RLT, MAX(9 TEK_SLT: TEK shortened lifetime, TEK_RLT: TEK Remaining LIfeTime, TEK_CLT: TEK Configured LIfeTime now‖ option of the If the GMs need to be rolled over to the new SAs immediately, we can use the ―replace - triggered rekey. This option might cause traffic to drop during the switchover as the old SAs are deleted ately. The command is: immedi - now - KS701#crypto gdoi ks rekey replace Primary T iggered Rekey restrictions: r Triggered rekey can be done only on the primary KS. The comman d is rejected when executed on the 1. : is displayed ollowing error message The f secondary KS. KS702#cry gdoi ks rekey - Secondary ERROR for group GET: This command must be executed on Primary KS - All GMs and KSs in the GETVPN network must support this feature for the triggered rekey to be effective. 2. ollowing behavior occurs The f when any of the KSs/GMs do not support this feature:  The KS will only send a triggered rekey with NO policy - replacement. The  GM s will install the new SAs but it will NOT reduce old SA lifetime It is possible to determine which of the KSs/GMs support this feature using the following command on the Primary KS : replace Primary - KS701#sho w cry pto gdoi feature policy - Group Name: GET Feature Supported Version Key Server ID 1.0.2 172.16.4.2 Yes 172.18.5.2 1.0.2 Yes Feature Supported Group Member ID Version Yes 1.0.2 172.19.1.2 1.0.1 No 172.20.2.2 of Page 114 220 © 2018 Cisco Systems, Inc. Cisco Confidential/Proprietary GETVPN Design and Implementation Guide

115 of 220 Page 115 © 2018 Cisco Systems, Inc. Cisco Confidential/Proprietary GETVPN Design and Implementation Guide

116 Enterprise Deployment 4. Depending on size, location, and other parameters, every enterprise has its own network design. Because each customer has a unique set of requirements, there is no single, typical enterprise network layout that every design constraint. Although enterprise network designs differ from one customer to can satisfy another, some common branch and data center (DC) networking elements can be used to select a branch or DC design that meets a particular customer‘s requirements. DC and Branch Designs 4.1 In any enterprise network, two major design considerations are the DC (where data is stored securely) and the branches (where data is consumed and generated). The intention of this guide is not to help a user networks etwork, but to help that user seamlessly integrate design the DC or branch n GETVPN GETVPN into an existing customer deployment. 4.1.1 DC Design This section examines a simplified typical DC network and some of its basic components. The network is it. over deployed be can GETVPN how explain to then used as an example GETVPN on the DC components is explained. As part of design considerations, the effect of key servers (KSs) and group members (GMs) GETVPN We also consider the placement of within the DC, and the correspondin g design factors. 4.1.2 Branch Design incorporate The Cisco Enterprise Branch Architecture introduces the concept of three branch profiles that not common branch network components. These three profiles are the only architectures recommended for works, but they represent various aspects of branch network designs. These profiles are used as branch net base lines with which all the integrated services building blocks and application networking services are built. For this guide, a network design was selected t hat not only follows the Enterprise Branch Architecture recommendation, but also covers certain technology variations within each branch. of Page 116 220 © 2018 Cisco Systems, Inc. Cisco Confidential/Proprietary GETVPN Design and Implementation Guide

117 Figure 32. Network Design Overview - Tier Branch Profile 4.1.2.1 Single This profile is recommended for smaller enterprise branch es that do not require platform redundancy and have a limited number of users. The WAN circuit (T1 or DS3) is terminated on the router (typically ISR), and LAN devices are connected using EtherSwitch module or a Layer 2 (L2) switch. High availability (HA), if GETVPN does not work over required, is achieved through less expensive cable or DSL backup. Because the Internet, a traditional IPsec tunneling solutions is deployed over the backup link. network design: The following profile variations can be deployed as part of the Branch with no backup  Branch with Dynamic Multipoint VPN (DMVPN) over the backup link  Branch with FlexVPN over the backup link   Branch with Virtual Tunnel Interface (VTI) over the backup link of Page 117 220 © 2018 Cisco Systems, Inc. Cisco Confidential/Proprietary GETVPN Design and Implementation Guide

118 4.1.2.2 Dual - Tier Branch Profile mprises two WAN termination routers, each typically connected to a different WAN provider. This profile co tier branch profile. - Dual WAN links and box redundancy provide a greater level of HA compared to the single terprise branch networks. LAN connectivity is This branch is typical of most branches in traditional en provided by a desktop switch (L2 or L3). Because the GETVPN routers all share the same policies, asymmetric routing is not an issue and we do not need stateful IPsec HA. rfaces, asymmetric traffic flows do not work. Note: If a firewall is enabled on the WAN inte The following profile variations were part of network design: Dual WAN termination on one branch router  Dual WAN termination on dual branch routers  is GETVPN ent (CPE); Dual WAN termination on dual provider customer premises equipm  terminated on enterprise owned branch router 4.1.2.3 Multitier Branch Profile This profile consists of dual WAN termination devices, single or dual Adaptive Security Appliance (ASA) tegration, and several desktop switches. This profile has appliances for security, dual routers for services in the most network gear but provides the greatest amount of HA and redundancy. The top layer routers provide WAN termination, the ASA appliances provide security services, and the middle layer routers provide integrated services termination. The external desktop switches provide LAN GETVPN can be terminated on the WAN aggregation devices (preferred) or services layer. connectivity. ultitier branch profile closely Redundancy and HA are provided at every (or almost every) device. The m resembles a small campus and large enterprise branches. GETVPN network is terminated on the WAN termination devices and a KS is also deployed in If the Note: figured to permit control plane the branch (as shown in the preceding topology), KS policies must be con traffic to and from the KS to go through the GM without IPsec encryption. 4.2 DC Design deployment in a typical DC environment: placement of KSs and GMs and This section examines GETVPN their interaction with existing servic es such as firewall, quality of service (QoS) and multicast architecture. - 3 2 provide MPLS or IP - 1 and AGG 3 shows a typical DC design. The WAN aggregation routers AGG Figure s and GM in reference to WAN connectivity. Further discussions in this section refer to placement of the KS these WAN aggregation devices. DC design is out of scope for this document. of Page 118 220 © 2018 Cisco Systems, Inc. Cisco Confidential/Proprietary GETVPN Design and Implementation Guide

119 Deployment GETVPN Figure 33. DC before GETVPN 4.2.1 DC Design Considerations To deploy GETVPN at the DC, consider the following components: be placed at geographically important locations. The DC provides an KS  : redundant KSs should ideal location to place a KS because it can be administratively monitored with the rest of the DC security devices. At the same time, KS can take advantage of the DC Edge router firewall and other provisions.  : The traffic to and from the DC needs to be encrypted. One or more GMs provide this GMs functionality. be taken control plane traffic operates on UDP port 848. Consideration needs to GETVPN : Traffic  e it to the KSs and GMs as needed. to ensure that this traffic can mak : For detailed information about KS design, see Chapter 3, ―System Design.‖ Tip 4.2.1.1 KS in DC Design With redundant KSs in the system, KSs can be placed in different locations/sites or they can be put together le site. See 3.7.3.1 ―Selecting the Number of COOP KSs‖ and 3.7.3.2 ―Setting KS Priority‖ for on a sing recommendations for how many KS to consider and choosing KS priorities. In the case of a geographically ntinents), deploying a KS in each GETVPN network (for example, spanning multiple co disperse geographical area to handle the registration is preferred to reduce registration latency. of Page 119 220 © 2018 Cisco Systems, Inc. Cisco Confidential/Proprietary GETVPN Design and Implementation Guide

120 4.2.1.1.1 KS Placement An important consideration in the DC is the placement of the KS. The KS router is usually a - a - on - ―router ick‖. The only function of these routers is to handle the GDOI functionality. st 4 Figure 3 shows one of the ways in which the KS can be placed in the DC. Figure 34. DC with Deployed KS . This allows the KS to The KS are connected directly to the WAN aggregation devices in parallel to the GMs take advantage of the security policies placed on these aggregation devices. Placement of KS behind GM should have an the KS policy , when unicast rekey is used, a In deployments where KS is placed behind GM . Following is an example of the ACL entry to avoid encryp tion of the GDOI and COOP control plane traffic ACL entry: deny udp any eq 848 any eq 848 must transit. If there are only a traffic This policy should be applied to any GM where the GDOI and COOP try can be added as a local policy on the GMs to avoid encrypting the control small number of GMs, this en plane. On larger deployments, it would be easier to include the deny in the KS policy that is downloaded to all GMs. 4.2.1.1.2 KS Redundancy As shown in Figure 3 provides 4 , each KS shoul d have multiple links to the WAN aggregation devices. This 3.7.3.2 ―Setting KS for redundant links. In addition to that, multiple KSs can be placed in the DC. See Priority‖ for recommendations for KS priority selection. of Page 120 220 © 2018 Cisco Systems, Inc. Cisco Confidential/Proprietary GETVPN Design and Implementation Guide

121 face and Routing 4.2.1.1.3 KS Loopback inter protocol. For a KS, it is recommended to always use a loopback interface as the KS IP address for the GDOI The configuration below shows how to use the loopback interface as the server IP address in the KS configuration. ! ck0 interface Loopba ip address 1.2.3.4 255.255.255.255 ! crypto gdoi group server local address ipv4 1.2.3.4 ! Some consideration must be given to the routing that is configured at the DC. The KS IP address, that is, the e distributed into routing protocol at the DC. loopback interface, might need to b Another factor to note while considering the routing at the KS is network convergence. When a KS initializes, it goes through a COOP election process. If network convergence takes longer than the COOP process, the KS elects itself as a primary KS, emulating a false network split (see 3.7.4.2.2 ―Network Merge‖). tree mode on the One recommendation for reducing network convergence is to enable Port Fast spanning - switch port that the KS connects to. A lengthy conv ergence time is commonly attributed to introducing a new route or prefix into the dynamic routing protocols. If the prefix associated with the KS loopback interface is KS is dramatically persistently advertised into the network, the delayed reachability interval between the shortened. 4.2.1.1.4 KS Firewall Considerations If the DC WAN aggregation routers have a perimeter firewall used to protect the DC from the WAN, a separate DMZ can be created on the firewall for the KS. This enables the KS to remain isol ated from other devices and improves security. The following sample configuration on the FWSM creates a separate interface for the KSs. or ASA ! !Vlan13 terminates KS connections ! interface Vlan13 nameif key_servers lower than inside network -- < level 75 - security security level .0 0 255.255. 172.16.1.1 ip address ! of Page 121 220 © 2018 Cisco Systems, Inc. Cisco Confidential/Proprietary GETVPN Design and Implementation Guide

122 The firewall access control lists (ACLs) must be carefully configured to permit GDOI control traffic in and out ment traffic (telnet, SSH, and of the KSs. In addition, the ACL should allow routing traffic and other manage so on) to the KS. The following sample ACL configuration can be used for the firewall. This is not a complete configuration, and ACL configuration varies depending on user requirements. ! !Incoming ACL = KS_IN: Open ACL to al low all traffic from KS ! !Outgoing ACL = KS_OUT: Control traffic that goes to the KS ! access - list KS_IN extended permit ip any any list KS_OUT extended permit udp any any eq 848 - access list KS_OUT extended permit ospf any any - access ! group KS_IN in interface key_servers - access access - group KS_OUT out interface key_servers ! If the KSs are configured for multicast rekey, multicast firewall. - routing would need to be enabled on the The following sample configuration on a Catalyst 6500 Firewall Services Modu le (FWSM) supports multicast rekey traffic. ! routing - multicast ! ! RP = 10.200.200.200 pim rp - address 10.200.200.200 ! 4.2.1.2 GM Design The following section describes factors involved in GM design. GM Placement 4.2.1.2.1 The GM handles all the encrypte d traffic to and from the DC. For this reason, the GM must be placed inline . shows GM router placement 3 3 with the data path just after the WAN aggregation routers. Figure of Page 122 220 © 2018 Cisco Systems, Inc. Cisco Confidential/Proprietary GETVPN Design and Implementation Guide

123 Figure 35. DC with Deployed GMs 4.2.1.2.2 GM Redundancy and Load Balancing As with other dev ices, it is recommended to provide multiple link redundancy to the GM. As shown in Figure , each GM has dual links to the WAN aggregation devices and to the DC core. As 3 5 an example, in the DC , GM1 has two routes to either KS. shown in Figure 3 2 172.16.4.2 KS1 = -- < 172.16.4.2 route GM1#sh ip /32 172.16.4.2 Routing entry for Known via "ospf 10", distance 110, metric 14, type intra area Last update from 172.16.1.1 on GigabitEthernet0/1, 1w1d ago Routing Descriptor Blocks: , 172.16.4.2 , from * 172.16.1.1 1w1d ago, via GigabitEthernet0/3 Route metric is 14, traffic share count is 1 2 < -- G0/3 is link to AGG - , 1w1d ago, via GigabitEthernet0/1 172.16.1.1 , from 172.16.4.2 Route metric is 14, traffic share count is 1 -- < 1 - G0/1 is link to AGG of Page 123 220 © 2018 Cisco Systems, Inc. Cisco Confidential/Proprietary GETVPN Design and Implementation Guide

124 A DC typically ca rries high throughput traffic. To handle the DC traffic load, it is recommended to deploy - multiple GMs. This provides for redundancy and load balancing. Routing must be designed carefully at the DC so that GMs have the same routing knowledge to provide for load balancing. Figure 35 shows how two GMs are deployed. The following CLI snippets demonstrate the load balancing capability of the DC. .0/ is a destination available on the private network, 16 172.18.0 Consider an example in which network r through ISP1 or ISP2. reachable eithe As seen from a DC router R1, multiple routes are available for the destination network. .0 172.18.0 sh ip route R1# 172.18.0 Routing entry for 16 .0/ Known via "ospf 10", distance 110, metric 10 Tag 500, type extern 2, forward metric 2 Last update from 10.1.1.1 on GigabitEthernet0/1, 6d21h ago Routing Descriptor Blocks: 10.2.1.1, from 1 .1, 6d21h ago, via GigabitEthernet0/2 72.18.1 Route metric is 10, traffic share count is 1 Route tag 500 G0/2 is link to GM < -- - 2 72.19 1 , 6d21h ago, via GigabitEthernet0/1 1 .1. * 10.1.1.1, from Route metric is 10, traffic share count is 1 Route tag 500 < G0/1 is link to GM -- 1 - Cisco Express Forwarding (CEF) table for the destination can also verify load balancing. As seen in the show command below, th e load distribution is 01 01 01 ... and traffic share 1 shows equal cost per - destination load sharing at the access layer router. - internal 172.18.0.0 R1# sh ip cef 151.1.6.0/24, version 21109, epoch 0, per - destination sharing 0 packets, 0 bytes Flow: Origin AS 0, Peer AS 0, mask 24 via 10.2.1.1, GigabitEthernet0/2, 0 dependencies traffic share 1 next hop 10.2.1.1, GigabitEthernet0/2 valid adjacency via 10.1.1.1, GigabitEthernet0/1, 0 dependencies of Page 124 220 © 2018 Cisco Systems, Inc. Cisco Confidential/Proprietary GETVPN Design and Implementation Guide

125 traffic share 1 next hop 10.1.1.1, GigabitEthernet0 /1 valid adjacency 0 packets, 0 bytes switched through the prefix tmstats: external 0 packets, 0 bytes internal 0 packets, 0 bytes Load distribution: 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 (refcount 1) Hash OK Interface Address Packets 0 1 Y 10.2.1.1 GigabitEthernet0/2 2 Y GigabitEthernet0/1 10.1.1.1 0 Y GigabitEthernet0/2 10.2.1.1 0 3 4 Y GigabitEthernet0/1 10.1.1.1 0 5 Y GigabitEthernet0/2 10.2.1.1 0 0 10.1.1.1 6 Y GigabitEthernet0/1 10.2.1.1 GigabitEthernet0/2 Y 7 0 10.1.1.1 8 GigabitEthernet0/1 Y 0 gabitEthernet0/2 Y Gi 10.2.1.1 0 9 10 Y GigabitEthernet0/1 10.1.1.1 0 11 Y GigabitEthernet0/2 10.2.1.1 0 GigabitEthernet0/1 0 10.1.1.1 12 Y GigabitEthernet0/2 Y 13 10.2.1.1 0 0 10.1.1.1 14 Y GigabitEthernet0/1 15 Y 10.2.1.1 GigabitEthernet0/2 0 0 16 Y GigabitEthe rnet0/1 10.1.1.1 refcount 6 R1# Tip : To see the exact route that a packet with certain source and destination IP address might take, use the IP> - IP>

126 GM Loopback Interface and Routing 4.2.1.2.3 ultiple interfaces that are part of the same GDOI group, it is recommended to use a loopback If a GM has m interface to source the crypto. If a loopback interface is not used, each interface that handles encrypted traffic must register individually with the KS. ould see these as separate requests and must keep multiple records for the same GM, which also The KS w means sending multiple rekeys. If crypto is sourced from the loopback interface instead, the GM registers only once with the KS. s how this can be achieved: The following configuration show ! interface GigabitEthernet0/1 description *** To AGG - 1 *** crypto map dgvpn ! interface GigabitEthernet0/2 2 *** - description *** To AGG crypto map dgvpn ! interface Loopback0 ip address 1.2.3.4 255.255.255.255 ! crypto ma - p dgvpn local address Loopback0 ! If using a loopback interface for crypto, routing should be designed so that GM IP address has connectivity to all KSs. This means that the GM loopback IP address must be advertised via a routing protocol. When local addr ess is configured for a crypto map with gdoi group, the local address interface and Note: the cryptomap interface should be in the same VRF. Firewall Considerations for GMs 4.2.1.2.4 n devices that implement Special considerations must be taken to place the GM behind the WAN aggregatio a firewall. Certain firewalls, such as Cisco ASA or FWSM modules (for Catalyst 6500) might not be able to handle encrypted multicast traffic, i.e., the firewall cannot forward Encapsulating Security Payload (ESP) encapsulated multi cast traffic. In such scenarios, it is recommended to place the GMs outside of the firewall. Because only encrypted traffic traverses GMs, GMs need not be placed behind the firewall. This is true even without the presence of the multicast traffic. In the a a firewall, communication through GMs can bsence of be secured through ACLs that permit only management and encrypted traffic to and from the GM. Note: UDP encapsulation. Refer to CSCsk37000. - ASA and FWSM do not forward multicast traffic for non of Page 126 220 © 2018 Cisco Systems, Inc. Cisco Confidential/Proprietary GETVPN Design and Implementation Guide

127 Figure 3 6 shows that all encrypted traffic should bypass the firewall module of the Cisco 6500 that serves as the DC WAN aggregation router, but all unencrypted traffic from the branches passes through the firewall. Because all control plane traffic from the KSs use UDP e ncapsulation, the KSs can be secured behind the firewall even when multicast rekey is deployed. Note: It is recommended recommended to design the data center networks so that GM routers carry only encrypted traffic. This means that unencrypted traffic to and fro m the DC should be routed via a separate router, as shown in Figure 34. Figure 36. Encrypted Traffic to the GM Bypasses a Firewall sample ACL As mentioned, ACLs on the DC WAN aggregation router can protect the GMs. The following routing (DC OSPF (GDOI), 848 P traffic), (encrypted ESP permits UD protocol), and PIM. An actual ACL will differ, depending on user requirements. ! list 100 permit pim any any access - access - list 100 permit esp any any - access list 100 permit udp any any eq 848 any list 100 permit ospf any - access ip any any list 100 deny - access ! Vlan20 terminates GM connections on 6500 - ! SVI ! interface Vlan20 of 220 Page 127 © 2018 Cisco Systems, Inc. Cisco Confidential/Proprietary GETVPN Design and Implementation Guide

128 ip access group 100 out - ! Beyond the GM, unencrypted traffic now flows through the DC core. The firewall at the WAN aggregation cannot sniff into the encrypted traffic, so sufficient protection must be added to the DC LAN. It is recommended to deploy another firewall, such as an ASA, or provide firewall services as part of the DC aggregation layer. s part of the DC Aggregation layer. 7 3 Figure shows a typical DC with firewall services a Additional Firewall Services Deployed in the DC Figure 37. 4.2.1.3 QoS In a DC design, it is recommended not to deploy QoS functionality on the GMs to maintain optimal GM performance. If applications do not mark packets correctly , it is recommended to mark the traffic before the traffic reaches a GM (that is, at the access layer routers). Because Differentiated Services Code Point be (DSCP) bits are preserved after encryption, QoS features (shaping, policing, and queuing) can easily deployed on the aggregation routers, which typically handle QoS features in hardware. This helps free GM resources to act as a dedicated encryption device. It is recommended to consult for det ailed Cisco Enterprise QoS Solution Reference Network Design Guide QoS information. http://www.cisco.com/en/US/docs/solutions/Enterprise/WAN_and_MAN/QoS_SRND/Enterprise_QoS_SRND .pdf GETVPN escription of QoS handling with For a detailed d on the same device, see 4.3.4.1 ―QoS.‖ of Page 128 220 © 2018 Cisco Systems, Inc. Cisco Confidential/Proprietary GETVPN Design and Implementation Guide

129 Recommended DC QoS Features Placement Figure 38. The following sample access router configuration for marking traffic can be used as a reference.! Class Map to Classify the Traffic from D ata Center Network class - map match - any INBOUND - CALL - SIGNALING match protocol sip - - DATA - TRANSACTIONAL class any INBOUND map match - match protocol telnet any INBOUND class - map match - - NETWORK - MANAGEMENT match protocol snmp - - R SCAVENGE any INBOUND class - map match match protocol http map match - class VOICE - any INBOUND - match protocol rtp audio DATA - map match - any INBOUND - MISSION - CRITICAL - class match protocol smtp class - - any INTERACTIVE - VIDEO map match match ip dscp af41 - INTERACTIVE any INBOUND - - O VIDE - class map match match protocol rtp video any INBOUND STREAMING - VIDEO class - map match - - match protocol rtsp ! Policy to Mark the Traffic From Data Center Network policy map LAN - - INBOUND MARKING - VOICE - class INBOUND set ip dscp ef SIGNALING - CALL - class INBOUND set ip dscp ef of Page 129 220 © 2018 Cisco Systems, Inc. Cisco Confidential/Proprietary GETVPN Design and Implementation Guide

130 class INBOUND - INTERACTIVE - VIDEO set ip dscp af41 class INBOUND - STREAMING - VIDEO set ip dscp cs4 - CRITICAL - MISSION DATA class INBOUND - set ip dscp 25 NETWORK class INBOUND - - MANAGEMENT set ip dscp 25 DATA class INBOUND - TRANSACTIONAL - set ip dscp af21 ss INBOUND cla - SCAVENGER set ip dscp cs1 interface FastEthernet2/0.302 description *** Facing Data Center Network **** encapsulation dot1Q 302 MARKING - INBOUND - policy input LAN service - Traffic classes (TCs) are On the aggregation network switch, a sample configuration is as follows. consolidated because of the limited number of classes in the switch. ! Class Map to Classify the Traffic Already Marked by Access Routers class - VIDEO map match - any STREAMING - match ip dscp cs4 class - - any INTERACTIVE - VIDEO map match match ip dscp af41 class - map match - any VOICE match ip dscp ef match ip dscp af31 match ip dscp cs3 map match class - - any MISSION - CRITICAL - DATA match ip dscp 25 match ip dscp cs2 - any ROUTING - class map match match ip dscp cs6 - map match - class NGER any SCAVE of Page 130 220 © 2018 Cisco Systems, Inc. Cisco Confidential/Proprietary GETVPN Design and Implementation Guide

131 match ip dscp cs1 - any TRANSACTIONAL map match - - DATA class match ip dscp af21 - QOS ! Policy Map to Do QoS Shaping,Queuing & Policing policy - map GETVPN - POLICY class ROUTING bandwidth percent 3 class VOICE bandwidth percent 15 VIDEO - class INTERACTIVE bandwidth percent 15 class STREAMING VIDEO - bandwidth percent 20 - CRITICAL - class MISSION DATA bandwidth percent 10 random - detect DATA - class TRANSACTIONAL bandwidth percent 10 detect - random class SCAVENGER bandwidth percent 2 random detect - GigabitEthernet2/2/0 interface description *** TO Service Provider Network*** policy output GETVPN - QOS - service POLICY. - 4.3 Branch Design GETVPN implementation on various branch profiles mentioned in 4.1.2 This section provides an overview of ―Branch Design.‖ Single - Tier Branch HA 4.3.1 In a single - tier branch design, there is one link to the MPLS provider, and provides encryption on GETVPN the MPLS link. A less expensive cable or DSL link provides HA. To securely send traffic over an Internet of Page 131 220 © 2018 Cisco Systems, Inc. Cisco Confidential/Proprietary GETVPN Design and Implementation Guide

132 GETVPN must be enabled over this link, too. Because link, IPsec encryption GETVPN cannot be deployed the backup link. over Internet, a traditional IPsec tunneling solution must be deployed over Any (or all) of the following three IPsec solutions can be deployed as part of the br anch security design:  Branch with DMVPN over the backup link  Branch with EzVPN over the backup link Branch with VTI over the backup link  In the following design discussions, it is assumed that: Border Gateway Protocol (BGP). Tier 1 branches receive a default route from the MPLS PE using   The branch receives a dynamic address and a second default route (usually with a metric of 254) from the Internet provider  Corporate security policy does not permit split tunneling over the Internet. That is, all traffic (in cluding Internet traffic) must be encrypted and routed to Headquarters, where it goes through corporate firewalls. The underlying idea is straightforward: the default route over the backup link is advertised with a worse metric. If the MPLS path is unavail able, routing then directs all traffic via backup path. If the MPLS network loses connectivity (data path problem), no routing change is triggered. Cisco PfR (Performance Routing) can be deployed as discussed in 4.3.4.2 ―PfR.‖ This section does not cover b ranch security design in detail. Refer to SAFE documentation for Note: design recommendations: http://www.cisco.com/en/US/docs/solutions/Enterprise/Security/SAFE_RG /SAFE_rg.html Figure 39. Branch Redundancy Branch Redundancy Using DMVPN 4.3.1.1 spoke DMVPN network can be configured over the backup link to provide an encrypted - and - Internet A hub channel. The advantage of using DMVPN is its ability to set up GRE tunnels for namically addressed dy of Page 132 220 © 2018 Cisco Systems, Inc. Cisco Confidential/Proprietary GETVPN Design and Implementation Guide

133 spokes, and the ability to choose the routing protocol to run over the backup interface. Routing can then be controlled according to customer requirements to provide backup connectivity. The DMVPN solution also ing from the hub to the spoke networks. supports multicast stream In the DMVPN scenario, routing is controlled as follows: The Internet ISP default route (metric 254) is overwritten by the MPLS provider BGP default route 1. (metric 20) because of preferred metric. MVPN head end is installed pointing to the gateway advertised by the Internet A static route for D 2. ISP. 3. EIGRP advertises a third default route over the DMVPN tunnel interface that has a metric better route (BGP 20). 90) but worse than MPLS provider default – – than the ISP default route (EIGRP Under normal circumstances, therefore, the default route will direct all traffic to MPLS link. If the MPLS link is down and default route is withdrawn, the EIGRP default route is installed in the 4. routing table and all traffic is directed to the tunnel, where it is encrypted using DMVPN and directed to DMVPN hub. When the MPLS link comes back up, the default route learned via BGP is installed in the routing 5. table, and traffic automatically switches back to the MPLS (primary) link. use DMVPN supports dynamic routing, DMVPN is the preferred backup technology. Tip : Beca 4.3.1.1.1 Configuration on the Spoke ! crypto keyring VPN ! ! Key to 1 72.19.2.1 is for DMVPN HUB ! - - 172.19.2.1 key address - shared pre key ipsec123 pre key address - shared 0.0 0.0.0.0 key nsite123 0.0. ! ! This policy is for GETVPN ! crypto isakmp policy 10 encr aes 14 group hash sha256 lifetime 1200 ! ! This policy is for DMVPN ! crypto isakmp policy 20 of Page 133 220 © 2018 Cisco Systems, Inc. Cisco Confidential/Proprietary GETVPN Design and Implementation Guide

134 encr aes share authentication pre - group 14 live 30 crypto isakmp keepa ! ! No need for transform - set for GETVPN. This transform - set is for DMVPN ! set AES_SHA esp - sha - aes esp hmac - crypto ipsec transform - mode transport ! crypto ipsec profile dmvpn set AES_SHA set transform - ! getvpn crypto gdoi group identity numb er 61440 server address ipv4 172.16.4.2 server address ipv4 172.18.5.2 ! ! crypto map 10 gdoi getvpn_cm set group getvpn ! ! DMVPN Tunnel Configuration for Hub Spoke DMVPN - ! interface Tunnel1 bandwidth 1000 ip mtu 1400 .255. ip address 172.20.1.1 255 .0 255 ip nhrp authentication nsite 172.19.2.1 ip nhrp map multicast ip nhrp map 172.20.1.254 172.19.2.1 id 101 - ip nhrp network ip nhrp holdtime 1500 ip nhrp nhs 172.20.1.254 of Page 134 220 © 2018 Cisco Systems, Inc. Cisco Confidential/Proprietary GETVPN Design and Implementation Guide

135 mss 1360 ip tcp adjust - ip nhrp registration no unique - l source GigabitEthernet0/0 tunne 172.19.2.1 tunnel destination tunnel protection ipsec profile dmvpn ! ! Interface connecting to DSL/Cable Modem/Router ! interface GigabitEthernet0/0 description To Internet ISP ip address dhcp interval 30 - load dup lex full speed 100 ! interface GigabitEthernet0/1.203 description LAN Interface encapsulation dot1Q 203 ip address 1 92.168.1.1 255.255. 0 .0 ! interface Serial0/0/0 description TO MPLS WAN bandwidth 1459 no ip address rela - y encapsulation frame - service 24 - module t1 timeslots 1 relay lmi - type ansi frame - ! - point interface Serial0/0/0.102 point - to ip address 1 0 0 255.255. . 72.19.1.2 mss 1360 - ip tcp adjust getvpn_cm crypto map ! of Page 135 220 © 2018 Cisco Systems, Inc. Cisco Confidential/Proprietary GETVPN Design and Implementation Guide

136 ! Running EIGRP over DMVPN Tunnel ! router eigrp 10 1 255 .0 0.0. 92.168.0 network .255 network 172.20.1.0 0.0.0.255 - summary no auto ! router bgp 106 no synchronization bgp log - neighbor - changes 0 network 1 92.168.0 .0 mask 255.255. .0 neighbor 1 72.19.1.1 as 500 - remote neighbor 0/0/0.102 source Serial 172.19.1.1 update - summary - no auto ! ! IP route for DMVPN hub pointing to DHCP ! ip route 255.255.255.255 dhcp 172.19.2.1 ! Routing Table on the Spoke 4.3.1.1.2 The following show command illustrates normal behavior: - DMVPN GM#show ip route - Codes: C - connected, S - static, R - RIP, M - mobile, B BGP - D EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area OSPF NSSA external type 2 N1 - OSPF NSSA external type 1, N2 - OSPF external type 2 - OSPF external type 1, E2 - E1 - - IS - IS, su - IS - IS summary, L1 - i IS IS level - 1, L2 - IS - IS level - 2 user static route candidate default, U - IS inter area, * - - per - ia - IS periodic downloaded static route - ODR, P - o Gateway of last resort is to network 0.0.0.0 172.19.1.1 of Page 136 2 20 © 2018 Cisco Systems, Inc. Cisco Confidential/Proprietary GETVPN Design and Implementation Guide

137 172.20.0.0/24 is subnetted, 1 subnets C 172.2 0.1.0 is directly connected, Tunnel1 172.21.0.0/16 is subnetted, 1 subnets 172.21.0.0 is directly connected, GigabitEthernet0/0 C 172.19 .0.0/ 16 is subnetted, 1 subnets C 172.19.0 .0 is directly connected, Serial0/0/0.102 172.19.0 32 is subnetted, 1 subn ets .0.0/ S [1/0] via 1 7 2 . 21 .1.254 172.19.2.1 16 .0.0/ 192.168 is subnetted, 1 subnets C 192.168.0 .0 is directly connected, GigabitEthernet0/1.203 B* 0.0.0.0/0 [20/0] via 172.19.1.1 , 1w5d The following show command illustrates behavior when MPLS is down: DMVPN - GM# show ip route static, R Codes: C - connected, S - - RIP, M - mobile, B - BGP - D EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area - OSPF NSSA external type 1, N2 OSPF NSSA external type 2 N1 - OSPF external type 1, E2 E1 - OSPF external type 2 - - - IS - IS, su - IS - IS summary, L1 - IS - IS level - 1, L2 - i IS - IS level 2 ia IS - IS inter area, * - - candidate default, U - per - user static route periodic downloaded static route o - ODR, P - Gateway of last resort is 172.20.1.254 to network 0.0.0.0 172.20. 0.0/24 is subnetted, 1 subnets C 172.20.1.0 is directly connected, Tunnel1 172 . 2 1.0.0/ 16 is subnetted, 1 subnets C 172 . 2 1. 0 .0 is directly connected, GigabitEthernet0/0 172 .1 9 .0.0/ 16 is subnetted, 1 subnets 2.1 S 1 72 .1 9 . [1/0] via 1 7 2. 2 1.1.254 is subnetted, 1 subnets 16 1 92 .1 68 .0.0/ 1 C .0 is directly connected, GigabitEthernet0/1.203 0 . 68 .1 92 of Page 137 220 © 2018 Cisco Systems, Inc. Cisco Confidential/Proprietary GETVPN Design and Implementation Guide

138 D*EX 0.0.0.0/0 [170/297246976] via 172.20.1.254, 00:00:07, Tunnel1 Branch Redundancy Using VTI 2 4.3.1. Cisco IPsec VTI technology can be deployed over the backup link to p rovide an encrypted Internet channel. The advantage of using VTI is its ability to scale and support multicast streaming from hub to spoke. In the VTI scenario, routing is controlled as follows:  20) of the The Internet ISP default route (metric 254) is overwritten by the BGP default route (metric MPLS provider because of preferred metric.  A specific route for IPsec VTI gateway is added pointing to the Internet gateway. A static default route pointing to IPsec VTI is installed with a better metric than the I  nternet default, but worse than the BGP default.  If the MPLS link is down and the BGP default route is withdrawn, a static default route is installed in the routing table and all the traffic is directed to VTI. All traffic is encrypted and directed to VTI hub. When the MPLS link recovers, the default route learned via BGP is installed in the routing table,  and traffic automatically switches back to MPLS (primary) link. ! ! Policy for GETVPN ! crypto isakmp policy 10 encr aes group 14 lifetime 1200 ! ! Policy for VTI ! crypto isakmp policy 20 encr aes share authentication pre - group 14 ! ! Preshared key for VTI headend ! 172.19.2.1 crypto isakmp key ipsec123 address ! crypto isakmp key nsite123 address 0.0.0.0 0.0.0.0 crypto isakmp keepalive 30 ! of Page 138 220 © 2018 Cisco Systems, Inc. Cisco Confidential/Proprietary GETVPN Design and Implementation Guide

139 ! sha - aes esp - set AES_SHA esp - crypto ipsec transform hmac - 256 ! crypto ipsec profile VTI set transform - set AES_SHA ! crypto gdoi group dgvpn identity number 61440 server address ipv4 172.16.4.2 72.18.5.2 server address ipv4 1 server address ipv4 1 72 .15.3.2 ! crypto map dgvpn 10 gdoi set group dgvpn ! ! Virtual Tunnel Interface ! interface Tunnel1 .1.1 255.255. 255 .0 20 ip address 172. tunnel source GigabitEthernet0/2 tunnel destination 172.19.2.1 tunnel mode ipsec ipv4 tunnel protection ipse c profile VTI ! interface GigabitEthernet0/1 description TO MPLS WAN 255.255. 5 2 0 .1 .0 172 .1. ip address crypto map dgvpn ! interface GigabitEthernet0/2 description TO INTERNET 7 .1.101 255.255.255.0 2.1 6 ip address 1 ! of Page 139 220 © 2018 Cisco Systems, Inc. Cisco Confidential/Proprietary GETVPN Design and Implementation Guide

140 interface FastEthernet2/0 des cription TO LAN .0 0 255.255. .1 ip address 1 92 1 68 . 1 . ! router bgp 109 no synchronization bgp log - neighbor - changes .0 0 .0 mask 255.255. 192.168.0 network remote neighbor 172.15.1.254 - as 500 - source GigabitEthernet0/1 neighbor 1 72.15 .1.254 update no a uto summary - ! ! Default route to VTI – preferred over Internet Default Route ! ip route 0.0.0.0 0.0.0.0 Tunnel1 100 ! .1.254 1 2 .1 6 7 ip route 172.19.2.1 255.255.255.255 .1 Routing Table on the Spoke 4.3.1. 2 ior: The following show command illustrates normal behav show ip route GM# - VTI - Codes: C connected, S - static, R - RIP, M mobile, B - BGP - - EIGRP external, O EIGRP, EX - D - OSPF, IA - OSPF inter area N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2 E1 - OSPF external type 1, E2 - OSPF ext ernal type 2 - IS IS 2 - IS level i - - - IS, su - IS - IS summary, L1 - IS - IS level - 1, L2 - ia - IS - IS inter area, * - candidate default, U user static route - per periodic downloaded static route o - ODR, P - 172.15.1.254 Gateway of last resort is to network 0.0. 0.0 is subnetted, 1 subnets 24 .0.0/ 0 172.2 0 172.2 C .1.0 is directly connected, Tunnel1 of Page 140 220 © 2018 Cisco Systems, Inc. Cisco Confidential/Proprietary GETVPN Design and Implementation Guide

141 7 2.1 6 1 16 is subnetted, 1 subnets .0.0/ C 1 7 2.1 6 . 0 .0 is directly connected, GigabitEthernet0/2 1 .0.0/ 16 is subnetted, 1 subnets 72.15 C 1 72.15.0 .0 is directly connected, Gi gabitEthernet0/1 172.19 .0.0/32 is subnetted, 1 subnets [1/0] via 172.19.2.1 172.16.1.254 S 192.168 16 is subnetted, 1 subnets .0.0/ C 192.168.0 .0 is directly connected, FastEthernet2/0 B* 0.0.0.0/0 [20/0] via 172.15 .1.254, 1w6d The following show command ill ustrates behavior when MPLS is down: - VTI show ip route GM# - connected, S - static, R - Codes: C RIP, M - mobile, B - BGP OSPF inter area - OSPF, IA D - EIGRP, EX - EIGRP external, O - - N1 OSPF NSSA external type 2 - OSPF NSSA external type 1, N2 - OSP F external type 1, E2 - OSPF external type 2 E1 i - IS - IS, su - - IS - IS summary, L1 - IS IS level - 1, L2 - IS - IS level - 2 user static route ia - IS - IS inter area, * - candidate default, U - per - periodic downloaded static route ODR, P - o - is 0.0.0.0 to network 0.0.0.0 Gateway of last resort 172. 20 .0.0/ 24 is subnetted, 1 subnets C 172. 20 .1.0 is directly connected, Tunnel1 172 is subnetted, 1 subnets 16 6 .0.0/ .1 .1.0 is directly connected, GigabitEthernet0/2 172 .1 6 C 172 . 19 .0.0/32 is subnetted, 1 subnets 172.16 .1.254 [1/0] via S 172.19.2. 1 16 .0.0/ 192.168 is subnetted, 1 subnets .0 is directly connected, FastEthernet2/0 192.168.0 C 0.0.0.0/0 is directly connected, Tunnel1 S* GM# - VTI of Page 141 220 © 2018 Cisco Systems, Inc. Cisco Confidential/Proprietary GETVPN Design and Implementation Guide

142 4.3.2 Dual - Tier Branch HA tier branch profiles. This section provides an - As described in 4.1.2 ―Branch,‖ there are three typical dual implementations on dual GETVPN overview of tier branches. In the following section, the same GDOI policy - (GMs registering to the same GDOI group) is pushed down the GMs on both provider links. It is possible, however, that GMs register to different KSs (or groups) and download different GETVPN policies on different providers (one for Provider A and one for Provider - B). In this case, redundant providers - and security systems are deployed on the two links. Dual WAN Termination on a Single Branch Router (GM) 4.3.2.1 In this profile, a single router (GM) terminates two WAN circuits to provide link redundancy. It is recommended to use the loopback address as a registration address when attaching the same crypto the two redundant links. Otherwise, a KS sees this single GM as two distinct GMs. map on crypto map crypto_map_name local - address Loopback0 A sample configuration for this kind of branch is as following: crypto gdoi group dgvpn identity number 61440 172.16.4.2 address ipv4 server ! crypto map dgvpn local address Loopback0 - crypto map dgvpn 10 gdoi set group dgvpn interface GigabitEthernet0/0 description ***To Service Provider 1**** <..> crypto map dgvpn ! interface GigabitEthernet0/1 **** TO Service Provider 2 **** description <..> crypto map dgvpn of Page 142 220 © 2018 Cisco Systems, Inc. Cisco Confidential/Proprietary GETVPN Design and Implementation Guide

143 Figure 40. Dual WAN Termination on a Single Branch Router Dual WAN Termination on Dual Branch Routers (GMs) 4.3.2.2 s (GMs), each The most likely scenario to achieve dual tier branch redundancy is to use two branch router connected to a different service provider (SP), so that losing a single link or GM does not impact site connectivity. Unlike traditional IPsec solutions, GETVPN GMs share the same SAs and policies. Therefore, routing. the branch can handle asymmetric Figure 41. CEs Acting as GM – Dual Tier Branch A sample follows: GM1 crypto gdoi group dgvpn identity number 61440 172.16.4.2 server address ipv4 of Page 143 220 © 2018 Cisco Systems, Inc. Cisco Confidential/Proprietary GETVPN Design and Implementation Guide

144 crypto map dgvpn 10 gdoi set group dgvpn interface GigabitEthernet0/1 description *** To Service P rovider 1 *** crypto map dgvpn GM2 crypto gdoi group dgvpn identity number 61440 server address ipv4 172.18.5.2 crypto map dgvpn 10 gdoi set group dgvpn interface GigabitEthernet0/1 description *** To Service Provider 2 *** crypto map dgvpn .2.3 Dual WAN Termination on Provider CPE 4.3 In this case, the customer is provided two CPEs for connecting to two different service provider networks, and the customer cannot configure - on the CPEs. An enterprise owned branch router acts as a GETVPN GM GETVPN and connects to both CPEs. of Page 144 220 © 2018 Cisco Systems, Inc. Cisco Confidential/Proprietary GETVPN Design and Implementation Guide

145 – Dual Tier Branch Figure 42. GM behind SP CPEs A sample configuration follows. The configuration has the same design consideration as 4.3.2.1 ―Dual WAN Termination on a Single Branch Router (GM).‖ crypto gdoi group dgvpn identity num ber 61440 172.16.4.2 server address ipv4 ! address Loopback0 - crypto map dgvpn local crypto map dgvpn 10 gdoi set group dgvpn interface GigabitEthernet0/0 description ***To Service Provider 1 CPE**** <..> crypto map dgvpn ! ernet0/1 interface GigabitEth description **** TO Service Provider 2 CPE**** <..> crypto map dgvpn of Page 145 220 © 2018 Cisco Systems, Inc. Cisco Confidential/Proprietary GETVPN Design and Implementation Guide

146 4.3.3 Multitier Branch Redundancy - of view. deployment point GETVPN Multitier Branch HA is no different than that of the dual tier branch from The design consideration is the same as that of dual tier branch described in 4.3.2.2 ―Dual WAN Termination on Dual Branch Routers (GMs).‖ GETVPN 4.3.4 Common Branch Deployment Features Common GETVPN branch deployment features include:  QoS  Performance routing (PfR)  Wide Area Application Services (WAAS) 4.3.4.1 QoS GETVPN branch designs, we recommend that IP marking be done either by application or branch LAN In facing interface while shaping and queuing features to be deployed together on crypto map GETVPN 4 network is marked by the input ows that inbound traffic from branch LAN sh 1 attached interface. Figure QoS policy, while outbound traffic is handled by the output QoS policy. Figure 43. Sample Branch QoS Design 4.3.4.1.1 QoS Preclassify In every IOS IPsec solution, DSCP or TOS markings are pres erved during encryption process, that is, DSCP values are copied to the new outside header. If the packets were already marked with appropriate DSCP bits, QoS can be applied on the WAN interface based on these markings. IOS provides the flexibility to appl y QoS policies on the WAN interface based on original IP header or Layer 4 information (TCP/UDP ports, and a qos using so on). This can be achieved by classify command in the crypto map. - pre A network designer must be careful when choosing to use the qos pre - classify command. The packet processing order differs when this command in the configuration: classify With qos pre  - : 1. Classification 2. Marking 3. Policing 4. Encryption : 1. Encryption 2. Classification 3. Marking 4. Policing Without qos pre - classify  Also, this change of order changes how the ―show policy - map interface‖ displays the offered rate for a particular class. The following example shows the difference in display output with exactly the same traffic. classify, the offered rate is With qos pre clear traffic rate without any encryption overhead. -  - Class any) - map: VOICE (match of Page 146 220 © 2018 Cisco Systems, Inc. Cisco Confidential/Proprietary GETVPN Design and Implementation Guide

147 18361 packets, 3745644 bytes drop rate 45000 bps 30 second offered rate 244000 bps, Match: ip dscp ef (46) 18361 packets, 3745644 bytes 30 second rate 244000 bps Queuein g Strict Priority Output Queue: Conversation 72 Bandwidth 18 (%) Bandwidth 276 (kbps) Burst 6900 (Bytes) (pkts matched/bytes matched) 18361/4920748 (total drops/bytes drops) 2560/686080 with IPSec encryption overhead classify, the offered rate is the encrypted rate  - Without qos pre included. any) - map: VOICE (match - Class 16651 packets, 4462468 bytes drop rate 45000 bps 30 second offered rate 315000 bps, Match: ip dscp ef (46) 16651 packets, 4462468 bytes 30 second rate 315000 bps Queueing Strict Pr iority Output Queue: Conversation 72 Bandwidth 18 (%) Bandwidth 276 (kbps) Burst 6900 (Bytes) (pkts matched/bytes matched) 16651/4462468 (total drops/bytes drops) 2317/620956 Tip : If the QoS requirements can be satisfied by applying QoS policies based on DSCP/TOS bits, classify is not required. - configuring qos pre Sample QoS Configuration 4.3.4.1.2 A sample QoS design and configuration follows: ! For Classification of Inbound Traffic From LAN side map match class SIGNALING - CALL - any INBOUND - - ol sip match protoc of Page 147 220 © 2018 Cisco Systems, Inc. Cisco Confidential/Proprietary GETVPN Design and Implementation Guide

148 - map match - class - TRANSACTIONAL - DATA any INBOUND match protocol telnet NETWORK class map match - any INBOUND - - - MANAGEMENT match protocol snmp SCAVENGER - any INBOUND class - map match - match protocol http class - map match - any INBOUND - VOICE match protoco l rtp audio - class map match - any INBOUND - MISSION - CRITICAL - DATA match protocol smtp any INTERACTIVE - - class - map match VIDEO match ip dscp af41 map match - class - VIDEO - INTERACTIVE - any INBOUND match protocol rtp video class - map match - any INBOUND - STREAMING - VI DEO match protocol rtsp ! Policy For IP Marking On Traffic From LAN Side policy - map LAN - INBOUND - MARKING - VOICE class INBOUND set ip dscp ef - SIGNALING - CALL class INBOUND set ip dscp ef VIDEO - INTERACTIVE class INBOUND - set ip dscp af41 - class INBOUND - STREAMING VIDEO set ip dscp cs4 - DATA CRITICAL - MISSION class INBOUND - set ip dscp 25 - - MANAGEMENT NETWORK class INBOUND set ip dscp 25 SCAVENGER - class INBOUND set ip dscp cs1 of Page 148 220 © 2018 Cisco Systems, Inc. Cisco Confidential/Proprietary GETVPN Design and Implementation Guide

149 TRANSACTIONAL class INBOUND - DATA - set ip dscp af21 utbound Traffic Toward WAN ! For Classification of O map match - class any VOICE - match ip dscp ef match ip dscp af31 match ip dscp cs3 class - map match - any STREAMING - VIDEO match ip dscp cs4 - map match - DATA CRITICAL - any MISSION class - match ip dscp 25 match ip dscp cs2 map match - class any ROUTING - match ip dscp cs6 - map match - class any SCAVENGER match ip dscp cs1 class - map match - any TRANSACTIONAL - DATA match ip dscp af21 ! Policy for QoS Shaping and Queueing toward WAN POLICY - - map GETVPN - policy QOS class ROUTING percent 3 bandwidth class VOICE priority percent 15 VIDEO - class INTERACTIVE priority percent 15 VIDEO - class STREAMING bandwidth percent 20 class MISSION DATA - CRITICAL - bandwidth percent 10 random detect - of Page 149 220 © 2018 Cisco Systems, Inc. Cisco Confidential/Proprietary GETVPN Design and Implementation Guide

150 class TRANSACTIONAL - DATA bandwidth percent 10 random - detect class SCAVENGER bandwidth percent 2 detect random - ! Policy Attached to WAN Facing Interface to Do Shaping and Queueing interface GigabitEthernet0/1 description *** To Service Provider *** <...> crypto map dgvpn policy o POLICY service - - utput GETVPN - QOS ! Policy Attached to LAN Facing Interface to Do IP Marking interface FastEthernet2/0 description *** TO Branch LAN network**** <...> policy input LAN - service MARKING - INBOUND - 4.3.4.2 PfR - Because GETVPN dual - tier branches have mult iple paths, maintaining end to - end connectivity is vital in enterprise network operation. Cisco PfR (Performance Routing) technology can be deployed in branches with redundant links to route the traffic based on various network parameters such as delay, ji tter, and to overcome path failures. In this design we mainly use PfR to detect path failure and to throughput etc. maintain end to end connectivity. - - The prerequisite of this deployment is that a branch site should have at least two redundant links on two different subnets as PfR external links, and one subnet for internal link. For more information regarding PfR deployment, refer to . http://www.cisco.com/go/pfr d on a single branch router having dual WAN 4 , PfR is deploye In this example, as shown in Fig ure 4 GETVPN termination. PfR master router and PfR border router are on the same router, which also provides functionality. PfR fast - monitoring is used for monitoring connectivity to a critical site that hosts the LAN .2.0/24. To do this, an active probe is configured for one host address ( 192.168 .2.253) across the 68 .1 192 MPLS network. PfR passive monitoring is used for all other traffic on the external interfaces. Path failure for active monitored by loss of active probes, while throughput measurements determine path failure for traffic is detected - passive monitored traffic. If the network loses the in use path, traffic is rerouted to the alternate path. of 220 Page 150 © 2018 Cisco Systems, Inc. Cisco Confidential/Proprietary GETVPN Design and Implementation Guide

151 Figure 44. PfR in the GETVPN Environment r P 1 c r e d i v o S e r v i e e b o r 3 P 5 2 e . v 2 i . t c 8 6 A 1 . 2 9 1 G M E 1 / 0 t e n r e h t t i b a g i G p o o L a k 1 0 c . 0 1 . . 0 b 8 . 9 2 . 1 6 1 . 2 0 / 2 4 s n i L l a n r k e t x E e G g a b i t t h i r n e t 0 / 2 E 0 / 0 e G i g a b i t E t h e r n t e a n k n r l t n I L i A c t i v 1 e 9 2 P . i e d o v S r P e r c e v i 2 r 1 r o 6 b 8 e . 2 . 2 5 3 for auth between master and border OER router !KEY key chain BR1 key 1 key - string KEYSTRING ----- ! ----- OER Master Router Configruation oer master !oer - map DATACENTER defines special treatment for specific traffic policy - rules DATACENTER ! logging ! 10 .0.0.1 key - chain BR1 border interface GigabitEthernet0/2 internal interface GigabitEthernet0/1 external external interface GigabitEthernet0/0 ! learn throughput - periodic period 1 prefixes 250 - interval 0 monitor ge receive - type prefix - length 16 no max ran aggregation unreachable threshold 10 mode route control Page 151 of 220 © 2018 Cisco Systems, Inc. Cisco Confidential/Proprietary GETVPN Design and Implementation Guide

152 mode monitor passive ! ! ---- OER Border Router Configuration ---- oer border local Loopback99 .0.0.1 key 10 master - chain BR1 ! !Oer - map defines fast monitoring for traffic matching a prefix - list map DATACENTER 10 - oer list OER match traffic - class prefix - set mode select - exit good set mode route control set mode monitor fast set active probe echo - 192.168 .2.253 set probe frequency 10 ! map - list used by oer - !prefix 192.168 .2.0/24 is Datacenter LAN network, and hence critical !network ip prefix 192.168 - list OER seq 5 permit .2.0/24 ! master master PfR command can be used. Once operational, To verify PfR master operation, the show pfr status should show as ACTIVE. GM# sh master pfr ow OER state: ACTIVE ENABLED and Conn Status: SUCCESS, PORT: 3949 Version: 2.1 Number of Border routers: 1 Number of Exits: 2 Number of monitored prefixes: 2 (max 5000) Max prefixes: total 5000 learn 2500 Prefix count: total 2, learn 1, cfg 1 Border Status UP/DOWN AuthFail Version 0 2.1 ACTIVE UP 10 1d20h .0.0.1 <..> of Page 152 220 © 2018 Cisco Systems, Inc. Cisco Confidential/Proprietary GETVPN Design and Implementation Guide

153 Learn Settings: current state: STARTED time remaining in current state: 117 seconds throughput no delay no inside bgp no protocol - period 1 monitor - periodic interval 0 - - length 16 aggregation type prefix prefixes 250 exp ire after time 720 GM# To verify the PfR prefixes created by the PfR master, use the command show pfr master prefix . Fast monitoring creates its own prefix based on the prefix - - map. In our example, this list configured for the oer would be .2.0/24. 192.168 P assive monitoring creates its prefixes based on the traffic flow. In our example, the GM was carrying traffic to a destination 192 .1 68 .6.0/24, but the aggregation - type is configured for a prefix - length of 16. Therefore, passive monitoring creates the prefi 192 .1 68 .0.0/16. x GM# show pfr master prefix OER Prefix Statistics: - Passive, Act - Delay - Long term, Dly Short term, L - Active, S Pas - (ms), - Percentage below threshold, Jit - Jitter (ms), P - Mean Opinion Score MOS Los - Packet Loss (packets - per - mill ion), Un - Unreachable (flows - per - million), - Bandwidth (kbps), N - Ingress, Bw Egress, I - Not applicable E - U unknown, * - uncontrolled, + - - control more specific, @ - active probe all # - Prefix monitor mode is Special, & - Blackholed Prefix Hop, ^ % For ce Next - - - Prefix is denied BR CurrI/F Protocol Time Curr Prefix State PasSDly PasLDly PasSUn PasLUn PasSLos PasLLos of Page 153 220 © 2018 Cisco Systems, Inc. Cisco Confidential/Proprietary GETVPN Design and Implementation Guide

154 ActSDly ActLDly ActSUn ActLUn EBw IBw ActPMOS ActSLos ActLLos ActSJit ---------------------------------------------------------- ---------------- .1 68 .0.0/16 INPOLICY 0 10 192 Gi0/0 BGP .0.0.1 U U 0 0 0 0 N N N N 1 1 N N 192 .1 68 .2.0/24 INPOLICY @0 10 .0.0.1 Gi0/0 BGP U U 0 0 0 0 1 1 0 0 0 0 Use the following show command to display the active probes on PfR : sho probes pfr border active - GM# w - probes OER Border active Type = Probe Type Target = Target IP Address TPort = Target Port Source = Send From Source IP Address Interface = Exit interface Att = Number of Attempts Comps = Number of completions N - Not applicable DSCP echo Comps Att Interface Type Target TPort Source .1.1 .1 68 .2.253 N 172 . 16 192 Gi0/1 173 171 0 192 0 173 .2.253 Echo .1 68 N 172 . 15 .1.1 Gi0/0 173 is configured to control routing using the command mode route contr In the preceding example, PfR ol for both passive and active monitoring. BGP was used in the example. route information: PfR Use the following show command to display GM# border route bgp pfr show 172.15 .1.1 BGP table version is 2366, local router ID is - ped, h history, * valid, > best, i Status codes: s suppressed, d dam internal, - r RIB failure, S Stale of Page 154 220 © 2018 Cisco Systems, Inc. Cisco Confidential/Proprietary GETVPN Design and Implementation Guide

155 EGP, ? - IGP, e - Origin codes: i - incomplete OER Flags: C - Controlled, X - Excluded, E - Exact, N - Non - exact, I - Injected Network Next Hop OER Weight Path LocPrf 0 CEI .1.254 16 . .2.0/24 500 ? *> 1 92. 1 68 72 1 ! 4.3.4.3 WAAS Cisco WAAS portfolio of technologies and products give branch and remote offices LAN - like access to elivery, centrally hosted applications, servers, and storage. The solution provides powerful application d optimization acceleration, any of performance the optimize to WAN and based application in a WAN environment. The Cisco WAAS solution can be deployed - TCP in a GETVPN environment by using a WAAS appliance or network modules (ISR routers). igure WAAS services on a GM, we must configure the GM and the WAAS module (or To conf GETVPN appliance) attached to the GM. The WAAS solution also requires an appliance to be configured as a Central nd manages the appliances and Manager (CM). A CM is typically deployed in the DC and monitors a modules. To optimize TCP based traffic between a branch and the DC, the WAAS solution can be deployed 4 as shown in Figure 5 : Environment Figure 45. WAAS Deployment in a GETVPN 220 Page 155 of © 2018 Cisco Systems, Inc. Cisco Confidential/Proprietary GETVPN Design and Implementation Guide

156 Router Configuration 4.3.4.3.1 n is required on the router in addition to the The following configuratio GETVPN and routing configuration, All WAAS modules and appliances should be able to reach each other and the Central Manager, encrypted or in the clear. ! Enable TCP promiscuous service groups Destination IP Hash Source IP H - ! 61 ash; 62 – ! ip wccp 61 ip wccp 62 ! ! Apply WCCP redirection on WAN Interface ! interface GigabitEthernet0/0 ip address 1.1.1.1 255.255.255.0 ip wccp 62 redirect in crypto map getvpn ! ! Apply WCCP redirection on the LAN interface ! interface GigabitEthernet0/1.11 ip address 10.1.1.254 255.255.255.0 ip wccp 61 redirect in ! ! Service Interface automatically configured for ISR modules ! This configuration is not required when using Appliance WAE module ! Address and default gateway assigned to ! - Service - interface Integrated Engine3/0 ip address 192.1.1.254 255.255.255.0 ip wccp redirect exclude in module ip address 192.1.1.1 255.255.255.0 - service gateway 192.1.1.254 - module ip default - service no keepalive of Page 156 220 © 2018 Cisco Systems, Inc. Cisco Confidential/Proprietary GETVPN Design and Implementation Guide

157 ! 4.3.4.3.2 ance Configuration Module/Appli For the first configuration of the appliance, use the console connection to connect to the device and use the username admin with a password of default. To configure WAAS modules in ISR routers, telnet to the admin default as username and and address assigned to the serv ice interface (shown previously) and use password. 8 2007) ! WAAS version 4.0.13 (build b23 Sep ! hostname 3845 WAE - ! interface GigabitEthernet 1/0 - primary ! interface GigabitEthernet 1/0 0 ip address 192.1.1.1 255.255.255. no autosense bandwidth 1000 - full duplex exit ! ! The second Ethernet interface on the WAAS appliance is typically used ! as the management interface. It is not being used in this configuration ! interface GigabitEthernet 2/0 shutdown exit ! ult ip defa - gateway 192.1.1.254 ! register enable - no auto ! - mtu - ! ip path discovery is disabled in WAAS by default ! ntp server 10.3.1.254 ! of Page 157 220 © 2018 Cisco Systems, Inc. Cisco Confidential/Proprietary GETVPN Design and Implementation Guide

158 - wccp router list 1 192.1.1.254 wccp tcp promiscuous router - list - num 1 - wccp version 2 ! ! The following configuration must b e added if planning to use GRE return ! egress method wccp - method negotiated return intercept - - ! central - manager address 4.4.4.4 ! WAAS Configuration Verification 4.3.4.3.3 GETVPN a The following commands can be used to verify the operation of the WAAS solution in environment: - 3845 Spoke#sh ip wccp inter detail WCCP interface configuration details: GigabitEthernet0/1.11 Output services: 0 Input services: 1 None Static: Dynamic: 061 Mcast services: 0 Exclude In: FALSE Engine3/0 - Service Integrated - Output services: 0 Input services: 0 Mcast services: 0 TRUE Exclude In: Tunnel1 Output services: 0 1 Input services: None Static: Dynamic: 062 of Page 158 220 © 2018 Cisco Systems, Inc. Cisco Confidential/Proprietary GETVPN Design and Implementation Guide

159 Mcast services: 0 FALSE Exclude In: - Spoke#telnet 192.1.1.1 3845 Cisco Wide Area Application Services Engine 3845 - WAE login: admin Password: default 3845 - WAE# sh tfo connection summ Optimized Connection List Policy summary order: Our‟s, Peer‟s, Negotiated, Applied F: Full optimization, D: DRE only, L: LZ Compression, T: TCP Optimization IP:Port - Remote IP:Port - Policy PeerId d ConI Local 00:14:5e:83:03:b3 F,F,F,F 77 10.1.1.10 :3863 10.2.1.10 :80 show In addition to the preceding commands, interface counters can compare LAN and WAN data rates. Typically, the WAN traffic rate is a fraction of LAN data rate. In addition to impro ving latency and response times, WAAS reduces (compresses) TCP traffic flowing through the router to improve WAN utilization and CPU overhead due to the encryption process (less traffic to encrypt). . h fix for CSCsm35350 When using GRE return in WAAS solution, use a version wit Note: GETVPN 4.4 Deploying A GETVPN deployment is network is seldom deployed in a new customer deployment. Typically a GETVPN over an existing IP or MPLS network. In traditional IPsec deployments, this transition is relatively simple becaus e encryption policies explicitly define the source and destination addresses of the networks requiring encryption. Consider the following network on which encryption services must be enabled: of 220 Page 159 © 2018 Cisco Systems, Inc. Cisco Confidential/Proprietary GETVPN Design and Implementation Guide

160 Existing MPLS Connected Branches Figure 46. yment 4.4.1 Traditional IPsec Deplo In traditional IPsec, encryption policies (what must be encrypted) are defined by explicit ACL entries. This - 1, under the crypto map, the ACL must include the source means that on Branch and destination prefixes of the networks which need to be encr ypted and will be defined as: list 101 permit ip 10.1.1.0 0.0.0.255 10.2.1.0 0.0.0.255 - access - On Branch 2, the ACL is a mirror image: access list 101 permit ip 10.2.1.0 0.0.0.255 10.0.1.0 0.0.0.255 - e explicit, encryption takes place only between Because the source and destination entries shown above ar 1 and Branch - Branch 3 network (10.3.1.0/24) is sent and - 2 networks. Traffic to and from the Branch - received in the clear and is not impacted by the newly defined encryption policy. - n This makes migration from a enabled network relatively simple. unencrypted network to an encryption Migration can easily take place in phases, where a few branches are converted to encryption - enabled branches at a time. 4.4.2 eployment D GETVPN ed to keep the encryption policy (what needs to be encrypted) deployments, it is recommend GETVPN In compact by summarizing the source and destination addresses in the encryption domain to a few entries. It means in the above example, ACL defining prefixes will be defined as: rmit ip 10.0.0.0 0.255.255.255 10.0.0.0 0.255.255.255 - list 101 pe access This ACL entry will result in only one pair of IPsec SAs in the GMs. The problem with this approach is as GM and the branch successful ly 1, is configured as - soon as one of the branches, e.g. Branch GETVPN registers with the KS, the branch starts encrypting all the traffic to and from the 10.0.0.0/8 network and is of Page 160 220 © 2018 Cisco Systems, Inc. Cisco Confidential/Proprietary GETVPN Design and Implementation Guide

161 makes phased essentially cut from the whole network. This off ting networks. migration of the network devices impossible without major disruptions in preexis GETVPN Operating Modes 4.4.3 allows different types of special encryption, decryption and forwarding modes for IPsec SAs for GETVPN ease of deployment. It is important to understand these modes of GM operation in GETVPN to come up with a su ccessfully migration strategy. Since the encryption and decryption behavior of devices is different in each mode, Table 7 summarizes this behavior: the GETVPN Operating Modes GETVPN Table 5. ● Traffic direction with respect Behavior Mode to the GM ● ) Receiving (Incoming from Conformant (Normal Encrypted traffic matching policy is decrypted Encrypted traffic the WAN) not matching policy is dropped ● Clear traffic matching policy is dropped ● Clear traffic not matching policy is forwarded ● (Outgoing to the Sending Cle ar traffic not matching policy is forwarded in clear WAN) ● encrypted Clear traffic matching policy is ● Encrypted traffic matching policy is decr ypted Receiving (Incoming from - Receive Only Configured on KS and the WAN) ● Encrypted traffic not matching policy is dropped applicable to all GMs ● Clear traffic matching policy is forwarded to this registering Group ● Clear traffic not matching policy is forwarded ● (Outgoing to the Sending Clear traffic matching policy is forwarded WAN) ● is forwarded Clear traffic not matching policy ● Mode Passive Encrypted traffic matching policy is decrypted Receiving (Incoming from - the WAN) Configured on ● Encrypted traffic not matching policy is dropped individual GM and will ● c matching policy is forwarded Clear traffi - override the receive only option pushed by ● Clear traffic not matching policy is forwarded KS ● Sending encrypted Clear traffic matching policy is (Outgoing to the WAN) ● Clear traffic not matching policy is forwarded 4.4.4 Migration Strategy: Receive - Only SAs Migration to - network from a network without encryption, receive only SAs can be GETVPN a used while encryption services are deployed. To change IPsec SA behavior, issue the following command : on the KS crypto gdoi group dgvpn1 server local sa receive only - ! IPsec SAs are now installed in an inbound only direction. This can be verified by issuing the following command on the GM (or KS): sh cry gdoi GM# GROUP INFORMATION of Page 161 220 © 2018 Cisco Systems, Inc. Cisco Confidential/Proprietary GETVPN Design and Implementation Guide

162 : dgvpn1 Group Name : 101 Group Identity Rekeys received : 4 : Inbound Only IPSec SA Direction mode, the IPsec SA on the GM can receive both encrypted and cleartext traffic. The Inbound Only In outgoing GM traffic is not encrypted and is sent in clear. Configuring Inbound Only mode enables GETVPN to be deployed using the phased approach, at a time. Devices that have been configured as GETVPN a few devices GMs have the control plane ready, but the data plane is not engaged; no encryption will occur on any of the devices. This enables the GMs to be able to talk to other CEs that have not been configured as GMs. is verified, When the control plane (registration, rekeys, SA installation, and so on) operation of GETVPN sa encryption can be turned on all devices at the same time by removing the only command from - receive ekey being sent from the KS, changing the direction of the SA on the the KS. This results in an immediate r GMs to ―Inbound Optional‖. crypto gdoi group dgvpn1 KS1(config)# - gdoi - KS1(config group)# server local - - local - server)# no sa receive KS1(gdoi only KS1(gdoi - local - server)# end KS1# KS_SEND_UNICAST_REKEY: Sending Unicast Rekey - 5 - :39:03.442: %GDOI May 11 23 for 172.168.4.2 group dgvpn1 from address with seq # 1 pto gdoi cry ow GM# sh GROUP INFORMATION : dgvpn1 Group Name : 101 Group Identity : 5 Rekeys received IPSec SA Direction : onal Inbound Opti In Inbound Optional mode, the IPsec SA on the GM can receive encrypted and plain text traffic. Outgoing - GM traffic is encrypted (unlike Inbound Only mode). The GM actually automatically transitions from Receive Mode. - Mode to Conformant Only through Passive - Subsequent rekeys change the IPsec SA to normal mode, where SAs can receive only encrypted traffic and always send encrypted traffic: of Page 162 220 © 2018 Cisco Systems, Inc. Cisco Confidential/Proprietary GETVPN Design and Implementation Guide

163 GM# sh ow gdoi cry pto GROUP INFORMATION : dgvpn1 Group Name Group Identity : 101 : 0 Rekeys received Both IPSec SA Direc : tion Testing before Deploying 4.4.5 Migration Strategy – - 4.4.5.1 Receive only migration strategy configuration enables a user to override KS configuration and change the direction of the IPsec GETVPN esting encryption on certain sites or parts of the network SAs. This functionality can be very useful when t before deploying encryption over the complete network. only‖ mode, - deployment is completed with KS configured in ―receive GETVPN For example, if a a user can change the direction of the IPsec SA o n a few sites to test encryption and application behavior on those sites without affecting the complete network. The following CLI changes the IPsec SA direction: GM# crypto gdoi gm ipsec direction ? rypt the packet IPsec SA will only accept cipher text and will enc Both before forwarding it out inbound Specify IPsec SA inbound options GM# gdoi gm ipsec direction inbound ? crypto IPsec SA will accept both cipher/plain text and will forward the only packet in clear. /plain text and will encrypt the optional IPsec SA will accept both cipher packet before forwarding it out Rekey from the KS overrides user defined IPsec SA direction settings to the KS configured value. - Note: Users must to reissue the command to get the desired setting. trategy Passive Mode Migration S 4.4.5.2 - Passive Mode is useful for migration from a non IPsec environment to an IPsec environment in a contolled The GM is in Passive Mode fashion. as a transient state after which it will switch to normal (conformant) mode. The figure and statements be low describe what happens to data traffic that hits a group member that is configured to be in Passive Mode. of Page 163 220 © 2018 Cisco Systems, Inc. Cisco Confidential/Proprietary GETVPN Design and Implementation Guide

164 Passive Mode of Operation Figure 47. On the inbound side, If packets are in the clear and don‘t match any ACE, the packets are forwarded.   crypted and match the SPI, the packets are decrypted and forwarded. If packets are en If packets are encrypted but don‘t match the SPI, the packets are dropped.  On the outbound side,  If there is no match on the clear packet, the packet is forwarded. the deny, the packet is sent in the clear.  If there is a match on If there is a match on the permit and there is an SA, the packet is encrypted and sent.  If there is a match but there is no SA, the packet is dropped. of Page 164 220 © 2018 Cisco Systems, Inc. Cisco Confidential/Proprietary GETVPN Design and Implementation Guide

165 Provisioning, Verification, and Monitoring 5. GETVPN This chapter desc ribes using Cisco Security Manager (CSM) to deploy , the syslog capabilities of verification, and Simple Network Management Protocol (SNMP) polling. GETVPN , GETVPN 5.1 Deploying using CSM GETVPN manage Group Member (GM) and Key Server Cisco Security Manager (CSM) can be used to deploy and T . ―Flex Configuration‖ feature of the CSM can be used for (KS) configurations efficiently he powerful GETVPN deployments. r, with or Configuration commands can be used to create FlexConfig policy objects in the FlexConfig Edito without additional scripting language instructions. Note: FlexConfig provisioning is similar to deploying an IOS configuration template to one or more loyed devices. Modifying and redeploying some configurations might require negating certain previously dep commands using the no keyword. GETVPN can be deployed using FlexConfig by following a few easy steps: Step 1. Configure IOS Device to accept CSM connections:  Set up basic routing for connectivity between CSM and IOS devices. in the IOS devices (this results in the  Set up HTTPS: signed - generation of a self certificate on the router). Set up a user with privilege 15 for CSM to connect and configure the device:   d on IOS device (not needed if the user is defined with privilege level 15 Set up an enable passwor as shown in last step). Step 2. Discover devices: Use any of the four methods provided in CSM to add the devices  usernames, Follow the prompts and enter the required information (IP addresses,  enable passwords)  CSM populates the device table of Page 165 220 © 2018 Cisco Systems, Inc. Cisco Confidential/Proprietary GETVPN Design and Implementation Guide

166 Figure 48. CSM Device Discovery 5.1.1 Deploying Key Server Configuration Using CSM Deploying a key server (KS) configuration with CSM is a little tricky and requires some user intervention. KS ion requires the following steps: configurat  Generating and exchanging the RSA keys between the COOP KS Configuring pre shared keys (PSKs) or registering to a certificate authority (CA)  -  Defining IKE Phase 1 parameters  Defining GDOI group and policies rvers  Defining COOP se Generating and exchanging RSA keys is a one - time event and is most easily configured using IOS CLI. Similarly, registering to a CA is an interactive process and should be handled by CLI. Parameters such as policies, group information, and COOP can b e deployed either using CSM or CLI and therefore it is important to analyze the KS configuration to decide best way to deploy this configuration. Consider the following typical KS configuration: crypto isakmp policy 1 encr aes share - authentication pre 14 roup g hash sha256 ! of Page 166 220 © 2018 Cisco Systems, Inc. Cisco Confidential/Proprietary GETVPN Design and Implementation Guide

167 crypto isakmp key cisco123 address 0.0.0.0 0.0.0.0 ! ! a _sha esp es - hmac - sha - esp es crypto ipsec transform - set a ! crypto ipsec profile gdoi - set security association lifetime seconds 7200 set transform - set 3des_sha ! p dgvpn1 crypto gdoi grou identity number 101 server local rekey retransmit 10 number 2 rekey authentication mypubkey rsa getkey rekey transport unicast sa ipsec 1 profile gdoi match address ipv4 111 size 2 - replay time window address ipv4 6.4.2 172.1 redundancy local priority 100 172.18.5.2 peer address ipv4 ! list 111 permit ip 10.0.0.0 0.255.255.255 10.0.0.0 0.255.255.255 - access ! In the preceding configuration, while most of the configuration is common between the two KSs, parts of onfiguration (shown in ) are specific to a particular KS, that is, each KS has its own address, priority, bold c and COOP peers. There are two approaches for the KS configuration deployment: Deploy complete KS configuration as a FlexConfig.  ceding configuration is customized for each KS and is defined in This means the pre multiple FlexConfigs. These FlexConfigs are then assigned to their respective KSs. policy (timers, ACL) must be incorporated in every GETVPN Any changes to the ing the configuration. KS FlexConfig before redeploy of Page 167 220 © 2018 Cisco Systems, Inc. Cisco Confidential/Proprietary GETVPN Design and Implementation Guide

168 Deploy a common KS configuration using shared FlexConfig and use CLI to configure  KS specific commands. Because any changes made to the shared Flex Configuration must be deployed to all devices sharing the of inconsistency between KS policies are reduced using this deployment method. configuration, the chances This deployment method also helps overcome the inherent issue of configuration sync between the KS in phases. GETVPN current Descriptions of both methods follow. Users can sele ct either method. 5.1.1.1 Adding a KS Specific FlexConfig 1. Click the KS device icon. . FlexConfigs Click 2. Click the + button to add a new FlexConfig. 3. FlexConfig 4. In the selector menu box, click + to add a new FlexConfig. Give this configuration a . KS1_specific_config descriptive n ame, such as 5. KS configuration to the text box. complete Add the Flex Configuration Figure 49. Click 6. to save the configuration OK Double click the configuration (or add it to the right plane) 7. . OK Click 8. 9. e. The new FlexConfig is added to the KS devic of Page 168 220 © 2018 Cisco Systems, Inc. Cisco Confidential/Proprietary GETVPN Design and Implementation Guide

169 Applying Flex Configuration to a Device Figure 50. 10. Follow this procedure to create and attach the FlexConfigs to all KSs 11. to all KSs (File >Submit and Deploy) Deploy the configurations 5.1.1.2 Adding a Shared FlexConfig Using CLI, add the KS specific configuratio 1. n on all the KSs in the network: crypto isakmp key cisco123 address 0.0.0.0 0.0.0.0 172.18.5.2 crypto isakmp key coopkey address ! crypto gdoi group dgvpn1 identity number 101 server local 172.16.4.2 address ipv4 redundancy local priority 100 peer address ipv4 172.18.5.2 ! For CSM deployment: Click the KS device icon 1. FlexConfigs Click 2. Click the + button to add a new FlexConfig 3. of Page 169 220 © 2018 Cisco Systems, Inc. Cisco Confidential/Proprietary GETVPN Design and Implementation Guide

170 4. In the FlexConfig selector menu box, click + to add a new FlexConfig. Give this configuration a . KS_shared_config descriptive name, for e xample, 5. Add the shared KS configuration to the text box (similar to the following): crypto isakmp policy 1 encr 3des share authentication pre - group 2 ! sha - 3des esp - set 3des_sha esp - crypto ipsec transform - hmac ! gdoi crypto ipsec profile - set security association lifetime seconds 7200 set transform - set 3des_sha ! crypto gdoi group dgvpn1 server local rekey retransmit 10 number 2 rekey authentication mypubkey rsa getkey rekey transport unicast sa ipsec 1 profile gdoi atch address ipv4 111 m size 2 - replay time window ! list 111 permit ip 10.0.0.0 0.255.255.255 10.0.0.0 0.255.255.255 - access of Page 170 220 © 2018 Cisco Systems, Inc. Cisco Confidential/Proprietary GETVPN Design and Implementation Guide

171 to save the configuration 6. Click OK 7. Double click the configuration (or add it to the right plane) OK . 8. Click 9. nfig is added to the KS device The newly created FlexCo 10. Click the FlexConfig name to highlight it Go to Policy > Share Policy. 11. 12. Provide a descriptive name, such as KS_shared_config . OK . Click 13. 14. In CSM main window, you should see something like: icy CSM Main Window Showing the Shared Pol Figure 51. . Assigned to: 1 Devices Click 15. window, add the remaining KSs. Shared Policy Assignment for KS_shared_policy 16. In the 17. Click OK . : field will show the correct The FlexConfig will appear under all the KSs and the Assigned to 18. lexConfig is assigned. number of devices to which the F 19. Submit and deploy the configuration to the KSs. Note: After a successful CSM deployment, it is a good idea to issue a clear crypto gdoi on cast the KSs to force a COOP election. When configuring multicast rekey on the KS, ensure that the multi infrastructure is already in place and is working. 5.1.2 Deploying Group Member Configuration Using CSM Deploying the group member (GM) configuration using CSM is relatively simple. GM configuration can be aring the configuration amongst all the GMs. deployed by creating a FlexConfig and then sh In CSM, click any GM device icon 1. 2. FlexConfigs Click 3. Click the + button to add a new FlexConfig In the FlexConfig selector menu box, click + to add a new FlexConfig. Give this configuration a 4. . GM_shared_config h as descriptive name, suc 5. Add the configuration to the text box (similar to following): of Page 171 220 © 2018 Cisco Systems, Inc. Cisco Confidential/Proprietary GETVPN Design and Implementation Guide

172 crypto isakmp policy 1 encr 3des - authentication pre share group 2 ! crypto isakmp key cisco123 address 172.16.4.2 172.18.5.2 crypto isakmp key cisco456 address ! to gdoi group dgvpn1 cryp identity number 101 server address ipv4 172.16.4.2 server address ipv4 172.18.5.2 ! ! crypto map getvpn 10 gdoi set group dgvpn1 ! interface GigabitEthernet0/0 crypto map getvpn OK 6. Click to save the configuration. 7. Double click th e configuration (or add it to the right plane) . OK Click 8. The newly created FlexConfig is added to the GM device. 9. 10. Click on the FlexConfig name to highlight it . Policy > Share Policy Go to 11. Provide a descriptive name, such as . 12. GM_shared_policy1 Click . 13. OK he CSM main window, you should see something like: In t 14. CSM Main Window Showing the Shared Policy Figure 52. of Page 172 220 © 2018 Cisco Systems, Inc. Cisco Confidential/Proprietary GETVPN Design and Implementation Guide

173 . to: 1 Devices Assigned 15. Click In the Shared Policy Assignment for GM_shared_policy window , add all the GMs 16. Click 17. OK and the : field will show the correct number Assigned to 18. The FlexConfig will appear under all the GMs of devices to which the FlexConfig is assigned. 19. Submit and deploy the configuration to the GMs. If the GMs use different KSs as preferred KSs to distribute the registration load, more than one shared policy must be created and shared. For example: 1 registers to the KSs in the following order: GM - (preferred) server address ipv4 172.16.4.2 server address ipv4 172.18.5.2 But GM - 2 registers to the KSs in the reverse order referred) server address ipv4 (p 172.18.5.2 172.16.4.2 server address ipv4 Two different policies would have to be defined and shared among the appropriate GMs. GETVPN Syslog Capabilities 5.2 Syslog messages provide a valuable resource for monitoring and troubleshooting GETVPN . syslog on a GM/KS, use the following configuration. To enable ! logging trap - logging source - interface type> ! The logging trap command can be used to filter syslog messages based on the level. A trap level of 7 means that the router will send all messages to the syslog server. To enable viewing syslog messages on the CLI, enable terminal monitoring. This command should be used . carefully, as a high message rate can overwhelm the CLI ! terminal monitor ! When using syslog messages, it is recommended to enable NTP on the router. GETVPN lists and describes syslog messages associated with . Table 8 Syslog Messages GETVPN Table 6. Explanation Message en the primary KS and secondary KS are mismatched. The configuration betwe COOP_CONFIG_MISMATCH A KS has been added to the list of cooperative KSs in a group. COOP_KS_ADD of Page 173 220 © 2018 Cisco Systems, Inc. Cisco Confidential/Proprietary GETVPN Design and Implementation Guide

174 The local KS has entered the election process in a group. COOP_KS_ELECTION COOP_KS_REACH figured cooperative KSs is restored. The reachability between the con A KS has been removed from the list of cooperative KSs in a group. COOP_KS_REMOVE The local KS transitioned to a primary role from being a secondary server in a group. COOP_KS_TRANS_TO_PRI horized remote server tried to contact the local KS in a group. Could be considered a COOP_KS_UNAUTH An aut hostile event. COOP_KS_UNREACH The reachability between the configured cooperative KSs is lost. Could be considered a hostile event. COOP_KS_VER_MISMATCH KSs are ru nning different versions of the Cisco IOS code. COOP_PACKET_DROPPED A hard limit set on the driver buffer size prevents the sending of packets this size or larger. - The rekey message is rejected because the sequence numbe GDOI_REKEY_SEQ_FAILURE - r antireplay check failed. GDOI 3 3 GDOI - - GM_NO_CRYPTO_ENGINE No crypto engine is found due to a lack of resources or an unsupported feature requested. - The rekey has a larger pseudotime that exceeds the calculated allowable pseudotim e difference. PSEUDO_TIME_LARGE GDOI - 3 3 - GDOI The rekey has a smaller pseudotime that exceeds the calculated allowable pseudotime - PSEUDO_TIME_TOO_OLD difference. GDOI_ANN_TIMESTAMP_ LARGE - e that - GDOI The secondary KS receives from the primary KS an ANN that has a larger pseudotim 4 exceeds the calculated allowable pseudotime difference. 4 - GDOI_ANN_TIMESTAMP_ TOO_OLD The secondary KS receives from the primary KS an ANN that has a smaller pseudotime that - GDOI exceeds the calculated allowable pseudotime difference. GDOI - 5 - The secondary KS temporarily blocks a GM from registering in a group because it has not CO OP_KS_BLOCK_NEW_GM_REGISTER received a valid pseudotime from the primary KS. GDOI - 5 - COOP_KS_VALID_ANN_ The secondary KS keeps receiving ANNs with inva lid pseudotimes after three retransmits. The TIMER_EXPIRED - secondary KS temporarily blocks new group member registration until a valid ANN is received. The ACL has too many entries. GDOI will honor only the first 100 ACL entries specified. GDOI_ACL_NUM GDOI_REKEY_F During GDOI rekey the payload parsing failed on this GM from the KS. AILURE The ACL differences between a GM and KS are resolved and a merge took place. GM_ACL_MERGE GM_ACL_PERMIT The GM can support only an ACL for "deny." Any traffic matching the " permit" entry will be dropped. GM_CLEAR_REGISTER The clear crypto gdoi command has been executed by the local GM. A crypto map has been attached for the local GM. GM_CM_ATTACH A crypto map has been detached for the local GM. GM_CM_DETACH GM_CONV _SA_DUPLEX IPsec SAs have been converted to bidirectional mode in a group on a GM. IPsec SAs have been converted to bidirectional mode in a group on a GM by a CLI command. GM_CONV_SA_DUPLEX_LOCAL to map in a group with a KS. A GM has enabled ACL on a GDOI cryp GM_ENABLE_GDOI_CM During GDOI registration protocol, a message sent by the KS has bad or no hash. GM_HASH_FAIL GM_INCOMPLETE_CFG Registration cannot be completed because the GDOI group configuration may be missing the group ID, server ID, or both. register to - The IPsec SA created for one group may have been expired or cleared. Need to re GM_RE_REGISTER the KS. A message sent by the KS to delete the GM has been received. GM_RECV_DELETE of Page 174 220 © 2018 Cisco Systems, Inc. Cisco Confidential/Proprietary GETVPN Design and Implementation Guide

175 GM_RECV_REKEY Rekey received. GM_REGS_COMPL Registration complete. During GDOI registration protocol, a proposal sent by the KS was refused by the local GM. GM_REJECTING_SA_PAYLOAD icy during a A GM that is configured to join an IPv4 group has mistakenly received an IPv6 pol GM_REKEY_IPV4_POLICY_CHECK_FAIL rekey. This might be because of a configuration error on the KS in which the same group is configured with an IPv6 policy. during a A GM that is configured to join an IPv6 group has mistakenly received an IPv4 policy GM_REKEY_IPV6_POLICY_CHECK_FAIL rekey. This might be because of a configuration error on the KS in which the same group is configured with an IPv4 policy. A GM has not received a rekey message from a KS in a group. Currently unimplemented. GM_REKEY_NOT_RECD _MULTI GM_REKEY_TRANS_2 A GM has transitioned from using a unicast rekey mechanism to using a multicast mechanism. GM_REKEY_TRANS_2_UNI A GM has transitioned from using a multicast rekey mechanism to using a unicast mechanism. only ACL has b GM_SA_INGRESS een received by a GM from a KS in a group. A received - A GM has left the group. GM_UNREGISTER KS_BAD_ID A configuration mismatch exists between a local KS and a GM during GDOI registration protocol. g messages from a GM. Could be considered a holin - A KS has reached a condition of black KS_BLACKHOLE_ACK hostile event. KS_CLEAR_REGISTER The clear crypto gdoi command has been executed by the local KS. KS_CONV_SAS_DUPLEX IPsec SAs have been converted to bidirectional mode in a group. IP only mode in a group. sec SAs have been converted to receive KS_CONV_SAS_INGRESS - KS_FIRST_GM, GDOI, LOG_INFO A local KS has received the first GM joining the group. During GDOI registration protocol, a proposal sent by the KS was refused by the GM. KS_GM_REJECTS_SA_PAYLOAD During rekey protocol, an unauthorized member tried to join a group. Could be considered a KS_GM_REVOKED hostile event. KS_GROUP_ADD A configuration command has been executed to add a KS in a group. KS_GROUP_DELETE been executed to remove a KS from a group. A configuration command has KS_HASH_FAIL During GDOI registration protocol, a message sent by the GM has a bad or no hash. The last GM has left the group on the local KS. KS_LAST_GM KS_NACK_GM_EJECT The KS has reached a condition of not receiving an ACK message from a GM and has been ejected. RSA keys were not created or they are missing. KS_NO_RSA_KEYS The KS has successfully completed a registration in a group. KS_REGS_COMPL KS_REKEY_TRANS_2_MULTI d from using a unicast rekey mechanism to a multicast mechanism. The group has transitione KS_REKEY_TRANS_2_UNI The group has transitioned from using a multicast rekey mechanism to using a unicast mechanism. Sending multicast rekey. KS_SEND_MCAST_REKEY Sending unicast rekey. KS_SEND_UNICAST_REKEY KS_UNAUTHORIZED During GDOI registration protocol, an unauthorized member tried to join a group. Could be considered a hostile event. of Page 175 220 © 2018 Cisco Systems, Inc. Cisco Confidential/Proprietary GETVPN Design and Implementation Guide

176 The KS has received an unsolicited ACK message from a past GM or is under a DO KS_UNSOL_ACK S attack. Could be considered a hostile event. A GM has received a pseudotime with a value that is largely different from its own pseudotime. PSEUDO_TIME_LARGE A GM or KS has failed an antireplay check. REPLAY_FAILED The regi UNAUTHORIZED_IDENTITY stration request was dropped because the requesting device was not authorized to join the group. UNAUTHORIZED_IPADDR The registration request was dropped because the requesting device was not authorized to join the group. An unexpec ted signature key was found that frees the signature key. UNEXPECTED_SIGKEY Receiving registration from unregistered interface. Stop processing it. UNREGISTERED_INTERFACE Unexpected TEK protocol. UNSUPPORTED_TEK_PROTO 5.3 GDOI Event Trace ure provides a trace facility for troubleshooting GETVPN . This feature enables The GDOI Event Tracing feat monitoring of events, errors, and exceptions. During runtime, the event trace mechanism logs GETVPN the debug data. trace information in a buffer space. A display mechanism extracts and decodes The GDOI Event Tracing feature can be used to analyze the cause of a device failure. When the GDOI subsystem GETVPN Event Tracing feature is configured, the router logs messages from specific components into the device memory, which can be as trace messages that are stored in the memory viewed or saved to a file. How to Configure GDOI Event Tracing GDOI Event Tracing feature can be configured either in privileged EXEC mode or global configuration mode based on the desired parameters. The fo llowing command is used to configure GDOI event tracing. monitor event - trace gdoi {coop | infra | registration | rekey} - event gdoi : that are configurable trace options Following is a snapshot of the GM1#monitor event - trace gdoi ? coop GDOI CO OP Event Traces dump Dump all the event traces exit GDOI Exit Traces infra GDOI INFRA Event Traces registration GDOI Registation event Traces rekey GDOI rekey event Traces How to display information collected by GDOI event trace Following command shows the options available to display the information collected by the gdoi event monitor: GM1#show monitor event trace gdoi? - all Show all the traces in current buffer r back in the past back Show trace from this fa clock Show trace from a specific clock time/date coop GDOI COOP Event Traces - from boot Show trace from this many seconds after booting infra GDOI INFRA Event Traces of Page 176 220 © 2018 Cisco Systems, Inc. Cisco Confidential/Proprietary GETVPN Design and Implementation Guide

177 vents since last display latest Show latest trace e merged Show entries in all event traces sorted by time registration GDOI Registration event Traces rekey GDOI Rekey event Traces Example output of an event - trace enabled on a GM: - GM1#show monitor event doi merged all trace g *May 25 20:20:57.706: Registration_events: GDOI_REG_EVENT: REGISTRATION_STARTED: GM 10.1.20.2 to KS 10.1.11.2 for group G1 *May 25 20:21:08.970: Registration_events: GDOI_REG_EVENT: REGISTRATION_DO NE: GM 10.1.13.2 to KS 10.1.11.2 for group G1 *May 26 00:45:52.878: Rekey_events: GDOI_REKEY_EVENT: REKEY_RCVD: From 10.1.11.2 to 10.1.13.2 with seq no 131 for the group G1 ay 26 00:45:52.878: Rekey_events: GDOI_REKEY_EVENT: ACK_SENT: From 10.1.11.2 *M to 10.1.13.2 with seq no 131 for the group G1 of Page 177 220 © 2018 Cisco Systems, Inc. Cisco Confidential/Proprietary GETVPN Design and Implementation Guide

178 Verification GETVPN 5.4 GETVPN provides an enhanced set of syslog and show commands to verify the normal functionality and debug network problems. Some of the commonly used syslog and show commands are shown below. networks, conditions are common in Because error and failure narios. these show commands and syslog messages can help troubleshoot failure sce 5.4 .1 Verifying KS Operation This section describes various show commands that can be used to verify KS operation. 5.4 .1.1 show crypto gdoi GETVPN To display information about configuration on the KS, use the show crypto gdoi command in privileged EXEC mode. Primary_KS#sh crypto gdoi GROUP INFORMATION : 1234 : getvpn (Unicast) Group Identity Group Name : 2 Group Members : Both IPSec SA Direction : Local Active Group Server : Configured Redundancy 172.16.4.2 Local Address : Local Priority : 100 Local KS Status : Alive Primary : Local KS Role Group Rekey Lifetime : 86400 secs Group Rekey Remaining Lifetime : 85505 secs Rekey Retransmit Period : 10 secs Rekey Retransmit Attempts : 2 Group Retransmit Remaining Lifetime : 0 secs : 1 Number IPSec SA IPSec SA Rekey Lifetime : 7200 secs - profile - : gdoi getvpn Profile Name Replay method : Time Based of Page 178 220 © 2018 Cisco Systems, Inc. Cisco Confidential/Proprietary GETVPN Design and Implementation Guide

179 Replay Window Size : 5 SA Rekey : 789 secs Remaining Lifetime : ACL Configured - list 199 access : Local Group Server list .1.2 show cry pto gdoi ks acl 5.4 The show crypto gdoi command also shows the ACL 199 is being used to define interesting traffic (traffic to be encrypted or not - encrypted) for the group. To verify the ACL policies on the KS, use the show crypto gdoi ks acl command: _Key_Server# Primary show crypto gdoi ks acl Group Name: dgvpn1 Configured ACL: access - list 199 deny igmp any any access - list 199 deny pim any any access list 199 deny eigrp any any - access - list 199 deny udp any any port = 500 access - list 199 deny udp any any por t = 848 list .255.255 0 .0.0 0. 192.168 .255.255 0 .0.0 0. 168 . 192 permit ip access - 199 deny ip any any access 199 list - 5.4 .1.3 show crypto gdoi ks rekey The show crypto gdoi ks rekey command provides information about the rekey statistics, such as, how many rek eys were sent out, how many times rekey was retransmitted, the configured lifetime and remaining lifetime and so on. 5.4 .1.3.1 Multicast Rekey Primary_Key_Server# sh crypto gdoi ks rekey Group getvpn (Multicast) : 2 Number of Rekeys sent retransmitted : 4 Number of Rekeys KEK rekey lifetime (sec) : 86400 Remaining lifetime (sec) : 84664 : 10 Retransmit period Number of retransmissions : 2 : 7200 lifetime (sec) IPSec SA 1 220 Page 179 of © 2018 Cisco Systems, Inc. Cisco Confidential/Proprietary GETVPN Design and Implementation Guide

180 Remaining lifetime (sec) : 745 Number of registrations after rekey : 0 239.77.77.77 : ticast destination address Mul .1.3.2 Unicast Rekey 5.4 Primary_Key_Server# sh crypto gdoi ks rekey Group getvpn (Unicast) : 1 Number of Rekeys sent : 0 Number of Rekeys retransmitted KEK rekey lifetime (sec) : 86400 : 85597 Remaining lifetime (sec ) Retransmit period : 10 : 2 Number of retransmissions : 7200 IPSec SA 1 lifetime (sec) Remaining lifetime (sec) : 883 .1.4 show crypto isakmp sa 5.4 sho To display all current Internet Key Exchange (IKE) security associations (SAs), use the w crypto command in EXEC mode. Note that the IKE session between the GM and KS (shown as isakmp sa GDOI_IDLE) will time out after the configured IKE lifetime. An IKE session is only required for initial operation. A rekey SA (shown as GETVPN registration and does not need to stay up for normal GDOI_REKEY) however always stays in the IKE database. #sh crypto isakmp sa Primary_K S ISAKMP SA IPv4 Crypto src state conn - id dst slot status 172.16.4.2 192.168 .1.5 GDOI_IDLE 1002 0 ACTIVE GD OI_IDLE 0 ACTIVE 1003 172.16.4.2 10.1.1.9 1004 10.1.1.13 GDOI_IDLE 172.16.4.2 0 ACTIVE 172 ACTIVE .1 10.1.1.13 0 6 . 4.2 GDOI_REKEY 0 Note: When a primary KS is unconfigured from the GM, the rekey ISAKMP SA associated with the KS will be deleted from the GM. The GM will reregister with a KS in the order of the configuration. 5.4 .1.5 show crypto isakmp sa detail To display detailed information about all current Internet Key Exchange (IKE) security associations (SAs), show crypto use the isakmp sa detail command in EXEC mode. This com mand provides details about time left on the SA, encryption engine in use as well as details of authentication method etc. PSKs .1.5.1 5.4 Primary_Key_Server# sh crypto isakmp sa detail of Page 180 220 © 2018 Cisco Systems, Inc. Cisco Confidential/Proprietary GETVPN Design and Implementation Guide

181 Codes: C IKE configuration mode, D - Dead Peer Detection - traversal K - Keepalive s, N - - NAT - IKE Extended Authentication X psk - Preshared key, rsig - RSA signature RSA encryption renc - IPv4 Crypto ISAKMP SA - C id Local Remote I - VRF Status Encr Hash Auth DH Lifetime Cap. psk 1002 1 72.16.4.2 192.168 .1.5 ACTIVE aes sha 2 2 3:55:17 - id:Conn - id = SW:2 Engine 1003 10.1.1.9 ACTIVE aes sha psk 2 23:55:31 172.16.4.2 - id = SW:3 - Engine id:Conn ACTIVE aes sha 10.1.1.13 172.16.4.2 1004 2 23:55:43 psk id:Conn - id = SW:4 - Engine .1.5.2 PKI 5.4 sh cry pto isakmp sa detail Primary_Key_Server# - C Codes: IKE configuration mode, D - Dead Peer Detection K - Keepalives, N - NAT - traversal X - IKE Extended Authentication - RSA signature - Preshared key, rsig psk - RSA encryption renc IPv4 Crypto ISAKMP SA C - id Local Remote I - V RF Status Encr Hash Auth DH Lifetime Cap. 2 23:58:12 172.16.4.2 192.168 .1.5 ACTIVE aes sha rsig 1007 Engine - id:Conn - id = SW:7 ACTIVE aes sha rsig 10.1.1.9 2 23:58:22 1008 172.16.4.2 - id:Conn - Engine id = SW:8 of Page 181 220 © 2018 Cisco Systems, Inc. Cisco Confidential/Proprietary GETVPN Design and Implementation Guide

182 rsig 1009 172.16.4.2 10.1.1.13 ACTIV E aes sha 2 23:58:32 5.4 .1.6 show crypto gdoi ks member To display information about GMs registered with a Server, use the sh crypto gdoi ks member command. This command can be executed on any of the COOP KS. The output also indicates the KS address with which the GM originally registered. Primary_Key_Server# sh crypto gdoi ks member Group Member Information: Number of rekeys sent for group getvpn: 1 Group Member ID : 10.1.1.9 Group ID : 1234 Group Name : getvpn Key Server ID : 172.16.4.2 Rekeys se : 1 nt 1 Sent seq num: 0 0 0 0 0 Rcvd seq num: 1 0 Group Member ID : 10.1.1.13 : 1234 Group ID Group Name : getvpn Key Server ID : 172.16.4.2 Rekeys sent : 1 Rekeys retries : 0 Rekey Acks Rcvd : 1 Rekey Acks missed: 0 num : 1 Sent seq 0 0 0 0 : 1 num Rcvd seq 0 0 command also shows detailed information about number of rekeys and show crypto gdoi ks member The rekey retries sent to a specific GM. An incrementing count of ̳rekeys retries‘ and ̳Rekey Acks missed‘ can indicate problems with a GM. of Page 182 220 © 2018 Cisco Systems, Inc. Cisco Confidential/Proprietary GETVPN Design and Implementation Guide

183 Shown here is a sample output for a GM 192.168 .1.1 that is currently not responding to rekeys. This is indicated by missing rekey Acks for sequence numbers 13 and 14. Primary_Key_Server# show crypto gdoi ks member | b egin 192.168 .1.1 .1.1 192.168 Group Member ID : Gr : 61440 oup ID Group Name : dgvpn1 Key Server ID : 172.16.4.2 Rekeys sent : 8 Rekeys retries : 6 : 5 Rekey Acks Rcvd Rekey Acks missed: 2 0 0 14 13 : Sent seq num 0 0 : 0 Rcvd seq num 0 5.4 .1.7 show crypto gdoi ks coop crypto gdoi ks coop sh ̳ environment, use ow ‘ Ss in a To display information about COOP K GETVPN command. This command provides detailed information about the priorities and roles of various COOP devices. S sh crypto gdoi ks coop # Primary_K Crypto Gdoi Group Name:getvpn Local Key Server handle: 2147483652 Group handle: 2147483652, Local Address: 172.16.4.2 Local Priority: 100 , Local KS Status: Alive Local KS Role: Primary Primary Timers: Primary Refresh Policy Time: 20 Remaining Time: 17 Antireplay Sequence Number: 64 Peer Sessions: Session 1: Server handle: 2147483653 172.18.5.2 Peer Address: Peer Priority: 75 of Page 183 220 © 2018 Cisco Systems, Inc. Cisco Confidential/Proprietary GETVPN Design and Implementation Guide

184 Peer KS Status: Alive Peer KS Role: Secondary , Antireplay Sequence Number: 2 IKE status: Established Counters: Ann msgs sent: 61 Ann msgs sent with reply request: 1 Ann msgs recv: 1 Ann msgs recv with reply request: 2 Packet sent drops: 2 Packet Recv drops: 0 Total bytes sent: 33402 Total bytes recv: 1170 sh crypto gdoi ks coop COOP_Key_Server# Crypto Gdoi Group Name:getvpn Group handle: 2147483650, Local Key Server handle: 2147483650 L ocal Address: 100.1.1.5 Local Priority: 75 , Local KS Status: Alive Secondary Local KS Role: Secondary Timers: Sec Primary Periodic Time: 30 Remaining Time: 11, Retries: 0 Antireplay Sequence Number: 3 Peer Sessions: Session 1: Server handle: 2147483651 eer Address: 100.1.1.1 P Peer Priority: 100 , Peer KS Status: Alive Primary Peer KS Role: Antireplay Sequence Number: 63 of Page 184 220 © 2018 Cisco Systems, Inc. Cisco Confidential/Proprietary GETVPN Design and Implementation Guide

185 IKE status: Established Counters: Ann msgs sent: 0 Ann msgs sent with reply request: 2 Ann msgs recv: 61 t: 0 Ann msgs recv with reply reques Packet sent drops: 1 Packet Recv drops: 0 Total bytes sent: 1074 Total bytes recv: 33346 5.4 .2 Verifying GM Operation This section describes various show commands that can be used to verify GM operation. 5.4 .2.1 show crypto isakmp sa rrent IKE SAs, use the command. Note that the IKE session To display all cu between the GM (shown as GDOI_IDLE) and KS will time out after the configured time. When a GM registers with the KS, two IKE SAs are created - GDOI_IDLE and GDOI_REKEY. GDOI_ID LE SA gets deleted after the configured lifetime but GDOI_REKEY SA stays in the IKE database. GroupMember 1# sh ow - crypto isakmp sa IPv4 Crypto ISAKMP SA dst id slot status - conn state src 10.1.1.9 172.16.4.2 GDOI_REKEY 2060 0 ACTIVE 172.16.4.2 10.1. 1.9 GDOI_IDLE 4038 0 ACTIVE 5.4 .2.2 show crypto gdoi command on the gdoi To display information about GETVPN configuration on the GM, use the show crypto parameters. GETVPN GM. This command provides a summary of all the useful 1# i GroupMember - crypto gdo sh ow GROUP INFORMATION : getvpn Group Name Group Identity : 1234 : 1 Rekeys received : Both IPSec SA Direction 172.16.4.2 : Active Group Server Group Server list 172.16.4.2 : of Page 185 220 © 2018 Cisco Systems, Inc. Cisco Confidential/Proprietary GETVPN Design and Implementation Guide

186 172.18.5.2 GM Reregisters in : 618 secs Rekey Received(hh:mm:ss): 00:03: 37 Rekeys received : 1 Cumulative : 1 After registration : 1 Reke ‟ Acks sent : 172.16.4.2 ACL Downloaded From KS permit ip 10.1.0.0 0.0.255.255 10.1.0.0 0.0.255.255 list - access KEK POLICY: Rekey Transport Type : Unicast : 85615 Lifetime (secs) Encrypt Algorithm : 3DES Key Size : 192 : HMAC_AUTH_SHA Sig Hash Algorithm Sig Key Length (bits): 1024 TEK POLICY: FastEthernet0/1: IPsec SA: sa direction:inbound spi: 0xC920B5B0(3374364080) transform: esp hmac sha - - - aes esp sa timing:remaining key li fetime (sec): (681) Anti - Replay(Time Based): 5 sec interval IPsec SA: sa direction:outbound spi: 0xC920B5B0(3374364080) hmac - sha - aes esp - transform: esp of Page 186 220 © 2018 Cisco Systems, Inc. Cisco Confidential/Proprietary GETVPN Design and Implementation Guide

187 sa timing:remaining key lifetime (sec): (681) - Replay(Time Based): 5 sec interval Anti .2.3 show cryp 5.4 to gdoi gm rekey The show crypto gdoi gm rekey command provides rekey statistics, for example, how many rekeys were received since the first registration, how many rekeys were received since the most recent registration, how many ACKs were sent (unicast re key), multicast group (multicast rekey), and so on. 5.4 .2.3.1 Multicast Rekey ow GroupMember - 1# sh crypto gdoi gm rekey Group getvpn (Multicast) Number of Rekeys received (cumulative) : 9 Number of Rekeys received after registration : 9 Multicast destinati on address : 239.77.77.77 Rekey (KEK) SA information: cookie dst src conn - id my - cookie his - 0F770714 3E281825 2063 172.16.4.2 : 239.77.77.77 New 3E281825 Current: 239.77.77.77 2063 172.16.4.2 0F770714 --- --- --- Previous: --- --- GroupMember - 1# sh ip igmp groups IGMP Connected Group Membership LastReporter Expires Uptime Interface Group Address 00:02:12 239.77.77.77 FastEthernet0/1 3w1d 10.1.1.9 224.0.1.40 10.1.1.9 00:02:10 3w1d FastEthernet0/1 .2.3.2 Unicast Rekey 5.4 - 1# sh crypto gdoi gm rekey GroupMemb er Group getvpn (Unicast) Number of Rekeys received (cumulative) : 1 Number of Rekeys received after registration: 1 Number of Rekey Acks sent : 1 Rekey (KEK) SA information: of 220 Page 187 © 2018 Cisco Systems, Inc. Cisco Confidential/Proprietary GETVPN Design and Implementation Guide

188 dst src conn - id my - cookie his - cookie 72.16.4.2 New : 10.1.1.9 1 2065 CEC03E80 F3D7CB96 F3D7CB96 CEC03E80 2065 Current: 172.16.4.2 10.1.1.9 Previous: --- --- --- --- --- .3 KS and GM Syslog Messages 5.4 This section describes various syslog messages that can be used to verify GETVPN operation. 5.4 _REGSTER and GM_REGS_COMPL .3.1 Syslog GM When a GM first comes up, it goes through the registration process to the first listed KS in its configuration. The syslog message indicates that the GM started the registration process. GM_REGSTER 5 - GM_REGSTER: Start reg istration to KS - 172.16.4.2 for group dgvpn %CRYPTO . 192 using address .1.1 168 The message indicates that the GM successfully completed registration. GM_REGS_COMPL This message also identifies the KS with which the GM registered. %GDOI - 5 - GM_REGS_COMPL: Registration to KS 172.16.4.2 complete for group dgvpn using address 192.168.1.1 5.4 .3.2 KS_SEND_CAST_REKEY: The KS_SEND_UNICAST_REKEY and KS_SEND_MULTICAST_REKEY syslog messages are seen when the primary KS sends out a rekey to the group. These messages can be used to verify rekey behavior (timing, retransmits etc) in the GETVPN network. The message below is an example of a unicast rekey message. KS_SEND_UNICAST_REKEY: Sending Unicast Rekey for group getvpn from - - 5 %GDOI 172.16.4.2 address with seq # 1 case of unicast rekey mechanism, the rekey message can be an indicator of GM or network failure. If all In GMs in the GETVPN group reply back to a unicast rekey, rekey syslog messages are displayed with consecutive incrementing sequence numbers. END_UNICAST_REKEY: Sending Unicast Rekey for group getvpn from %GDOI - 5 - KS_S address seq # 1 with 172.16.4.2 KS_SEND_UNICAST_REKEY: Sending Unicast Rekey for group getvpn from - 5 - %GDOI address 172.16.4.2 with seq # 2 - KS_SEND_UNICAST_REKEY: Sending Unicast Rekey f or group getvpn from %GDOI - 5 address seq # 3 172.16.4.2 with However, if one or more GMs do not reply back with a rekey ACK, the primary KS sends out additional rekey messages (retransmissions) to the failing GMs. These retransmissions increment the rekey sequence show the rekey sequence number abnormally (based on number of retransmits sent). If syslog does not numbers incrementing properly (last sequence number + 1), this indicates that the primary KS is sending out me some rekey retransmissions because ACKs from so GMs is not being received. of Page 188 220 © 2018 Cisco Systems, Inc. Cisco Confidential/Proprietary GETVPN Design and Implementation Guide

189 5 - KS_SEND_UNICAST_REKEY: Sending Unicast Rekey for group getvpn from %GDOI - address 172.16.4.2 with seq # 9 5 - KS_SEND_UNICAST_REKEY: Sending Unicast Rekey for group getvpn from %GDOI - with seq # 12 172.16.4.2 address 5.4 .3.3 Sys log GM_RECV_REKEY GM_RECV_REKEY message at the GM indicates that the GM has received a rekey from the primary The KS. In the message shown below, the GM 192.168.1.1 received a rekey with sequence # 5 from the primary KS 172.16.4.2 to - 5 - ceived Rekey for group dgvpn from 172.16.4.2 %GDOI GM_RECV_REKEY: Re .1.1 with seq # 5 192.168 .3.4 Syslog GM_RE_REGISTER 5.4 message indicates that the GM did not receive the rekeys from the KS. GM GM_RE_REGISTER The ration of current IPsec SAs. attempts to reregister with the KS 60 seconds before the expi - 4 - %GDOI GM_RE_REGISTER: The IPSec SA created for group dgvpn may have expired/been cleared, or didn‟t go through. Re register to KS. - - 5 - GM_REGSTER: Start registration to KS 172.16.4.2 for group dgvpn %CRYPTO address 192.16 using 8 .1.1 5.4 .3.5 Syslog GM_REGSTER_IF_DOWN The GM_REGSTER_IF_DOWN message indicates that the source interface for the crypto map is down and hence GM is unable to register. If crypto map is sourced directly from a physical interface, this message is seen whe n that interface is down. If crypto map is sourced from a loopback interface, this message is seen only when the loopback interface is disabled. registration GM_REGSTER_IF_DOWN: Can‟t start GDOI - 4 - %CRYPTO as interface GigabitEthernet0/1 is down 5.4 .3.6 Sys log GM_CONN_NEXT_SER During the registration process, if the GM is not able to reach the first KS in its configuration, it tries the next KS listed in its configuration. The GM_CONN_NEXT_SER message is seen every time GM selects the next server in the list to register. %CRYPTO - - 5 GM_CONN_NEXT_SER: GM is connecting to next key server from the list .3.7 Syslog GM_DELETE 5.4 syslog message is displayed on all KSs when they delete a GM from the database. This GM_DELETE The ast rekeys, and after the GM failed to respond to three consecutive message is only seen in the case of unic rekeys (and rekey retransmissions). GM_DELETE: GM 10.1.1.9 deleted from group getvpn. - 4 - %GDOI of Page 189 220 © 2018 Cisco Systems, Inc. Cisco Confidential/Proprietary GETVPN Design and Implementation Guide

190 5.4 .4 CO O P Syslog Messages This section describes various syslog messages that can be used to verify COOP operation in a GETVPN environment. 5 - COOP_KS_ELECTION - 5.4 .4.1 Syslog GDOI When the COOP KSs come up (or GDOI is cleared), they go through COOP election process. At this instance following syslog messages can be seen on all the KSs. COO %GDOI - 5 - P_KS_ELECTION: KS entering election mode in group getvpn (Previous Primary = NONE) - 5.4 .4.2 Syslog GDOI 5 - COOP_KS_TRANS_TO_PRI COOP_KS_TRANS_TO_PRI message displays information When the COOP election process is completed, s message is seen on both the primary and the secondary KSs. When about newly elected primary KS. Thi the KSs come up for the first time and enter election process, there is no primary KS on the network. The previous primary is shown as . NONE COOP_KS_TRANS_TO_PRI: KS - - %GDOI 5 oup getvpn transitioned to in gr 172.16.4.2 Primary (Previous Primary = NONE) If a primary KS failure causes a reelection, the syslog message also indicates the IP address of the previous primary. 5 - in group getvpn transitioned to 172.18.5.2 %GDOI COOP_KS_TRANS_TO_PRI: KS - Primary (Previous Primary = 172.16.4.2 ) .4.3 Syslog COOP_KS_UNREACH and COOP_KS_REACH 5.4 The message is displayed when a KS loses connectivity with peer COOP KSs. A COOP_KS_UNREACH primary KS tracks the state of all secondary KSs and uses this message to i ndicate loss of connectivity to a secondary KS. A secondary KS only tracks the state of the primary KS. This message on the secondary KS indicates loss of connectivity with the primary KS. ary KSs, Note: Although the primary KS may lose connectivity to more than 1 second a syslog message is currently only displayed by the primary KS for the first failed Secondary KS (CSCsl52477). The following message indicates that the KS lost connectivity to COOP KS 100.1.1.5. 172.18.5.2 COOP_KS_UNREACH: Cooperative KS Unreachable in group - 3 - %GDOI getvpn When the connectivity is restored among the COOP KSs, a COOP_KS_REACH message is displayed. COOP_KS_REACH: Reachability restored with Cooperative KS - 5 172.18.5.2 %GDOI - in group getvpn. of Page 190 220 © 2018 Cisco Systems, Inc. Cisco Confidential/Proprietary GETVPN Design and Implementation Guide

191 SNMP Monitoring using GDOI MIB 5 5. MIB file to retrieve the T he CI SCO - GDOI - can be imported into an SNMP management station and parse d through the GDOI MIB Support for GETVPN feature. The XE 3.16 table objects and hierarchy information - GDOI GETVPN GDOI/COOP MIBS feature enhances the CISCO MIB via - additional SNMP MIB objects for key server parameters and traps for key server events. Thes are applicable to both GDOI and G - IKEv2 - SNMP is an application layer communication protocol that allows network devices to exchange management information. Through SNMP, network administrators can manage network performance, find and solve network problems. The GDOI MIB support is available in IOS from 15.2(1)T and IOS XE from 15.3(1)S/XE3.8. The MIB has and notifications include information about objects that correspond to the GDOI RFC 3547. The MIB objects GDOI groups, GM/KS peers, as well as the policies that are created or downloaded . The object identifier (OID) for GDOI MIB is 1.3.6.1.4.1.9.9.759 . Current implementation supports only ―get‖ operations and traps/n otifications. GDOI MIB Table Hierarchy 5.5.1 The MIB objects are categorized first by GDOI Group and then by peer type (KS or GM). Each peer has . Following is the hierarchy: KEK and TEK tables below it GDOI Group Table KS Table GM Table KS KEK KS TEK Selector GM TEK Selector GM KEK Table Table Table Table GM TEK Policy Table KS TEK Policy Table GDOI MIB Table Objects ollowing is a list of the MIB table objects (listed per group). F Group table objects: Specifies whether the group ID is an IP address, group number, hostname, and so -- Group ID type  on. Number of octets in the group ID value.  Group ID length -- Group ID value - -  Group number, IP address, or hostname. String value. -- Group name  220 Page 191 of © 2018 Cisco Systems, Inc. Cisco Confidential/Proprietary GETVPN Design and Implementation Guide

192 KS table objects:  KS ID type  KS ID length KS ID value   Active KEK -- SPI of the KEK that is currently used by the KS to encrypt the rekey message.  that was sent by the KS to the group. Last rekey sequence number -- Last rekey number GM table objects: GM ID type  GM ID length  GM ID value  -- Registered KS ID type ID type of the KS to which the GM is registered.   Registered KS ID length  Registered KS ID value  the GM to decrypt rekey messages. Active KEK -- SPI of the KEK currently used by Last rekey seq number -- Last rekey number received by the GM.  KS KEK table objects:  KEK index KEK SPI  -- KEK source ID information  Source ID type, ID length, and ID value.  ID. Port associated with the source -- KEK source ID port  Destination ID type, ID length, and ID value. -- KEK destination ID information  KEK destination ID port -- Port associated with the destination ID.  IP protocol ID -- UDP or TCP.  Key management algorithm (unused).  Encryption algorithm and key length (bits)  SI G payload hash algorithm, SIG payload signature algorithm, and SIG payload key length (bits).  Hash algorithm (will be reused from the IPsec MIB)  Diffie - Hellman group KEK original lifetime (seconds) Maximum time for which a KEK is valid. --   time (seconds) KEK remaining life (corresponds to the ACLs that are configured as part of the IPsec SA in the KS TEK selector table objects GDOI group configuration on the KS): - Tek selector index -- An integer index. Source ID type, ID length, and ID value. -- TEK source ID information - TEK source ID port -- Port associated with the source ID. - - TEK destination ID information -- Destination ID type, ID length, and ID value. - Port associated with the destination ID. -- TEK destination ID port TEK Security protocol - GDOI_PROTO_IPSEC_ESP prot -- ocol ID value in the SA TEK payload (see RFC 3547). KS TEK policy table objects: - An integer index. -- TEK policy index -- TEK SPI - Four octets of Page 192 220 © 2018 Cisco Systems, Inc. Cisco Confidential/Proprietary GETVPN Design and Implementation Guide

193 - Encapsulation mode -- Tunnel or transport. - Encryption algorithm and key length (bits) - Integrity and authentication algor ithm and key length (bits) - TBAR window size (seconds) TEK original lifetime (seconds) -- Maximum time for which a TEK is valid. - - TEK remaining lifetime (seconds) - TEK Status -- Inbound, outbound, or not in use. : GM KEK table objects - An integer index. -- KEK index KEK SPI - KEK source ID information Source ID type, ID -- - length, and ID value. Port associated with the source ID. - KEK source ID port -- - -- Destination ID type, ID length, and ID value. KEK destination ID information Port associated with - KEK destination ID port -- the destination ID. IP protocol ID UDP or TCP. -- - Key management algorithm (unused) - Encryption algorithm and key length (bits) - SIG payload hash algorithm, SIG payload signature algorithm, and SIG payload key length (bits) - Hash algorithm - Hellman group - Diffie - - KEK original lifetime (seconds) -- Maximum time for which a KEK is valid. - KEK remaining lifetime (seconds) GM TEK selector table objects (corresponds to the ACLs that are downloaded to the GM as part of the TEK policy from the KS):  TEK selector index -- An int eger index.  TEK source ID information -- Source ID type, ID length, and ID value. TEK source ID port -- Port associated with the source ID.  length, Destination ID type, ID -- and ID value.  TEK destination ID information ith the destination ID. -- TEK destination ID port  Port associated w --  TEK Security protocol GDOI_PROTO_IPSEC_ESP protocol ID value in the SA TEK payload (see RFC 3547). : objects GM TEK policy table -- TEK policy index  An integer index. -- Four octets.  TEK SPI -- Tunnel or transport.  Encapsulation mode ryption algorithm and key length (bits) Enc  Integrity and authentication algorithm and key length (bits)  TBAR window size (seconds)   Maximum time for which a TEK is valid. TEK original lifetime (seconds) --  TEK remaining lifetime (seconds) tbound, or not in use. TEK Status -- Inbound, ou  of Page 193 220 © 2018 Cisco Systems, Inc. Cisco Confidential/Proprietary GETVPN Design and Implementation Guide

194 : Notifications GDOI MIB Traps/ The GDOI MIB contains 2 types of Traps/Notifications: those generated by the KS and those generated by each GM. The following table has the detailed information: MIB SNMP Notifications Supported by the GDOI Table 7. Notification Description A KS first received a registration request from a GM. KS New Registration KS Registration Complete A GM completed registration to the KS. KS Rekey Pushed A rekey message was sent by the KS. An error n otification was received from the KS because of missing RSA keys. KS No RSA Keys GM Register A GM first sent a registration request to a KS. GM Registration Complete A GM completed registration to a KS. GM Re a KS. registration process with - A GM began the re Register - GM Rekey Received A rekey message was received by a GM. A GM sent an error notification because of a missing configuration. GM Incomplete Config A GM sent an error notification because it cannot process and install a rekey. GM Rekey Failure KS Role Change A KS switches between primary and secondary role Generated when a GM is deleted from the KS. KS GM Deleted Generated by a KS when unreachable COOP peer becomes reachable. KS Peer Reachable KS Peer Unreachable hable COOP peer becomes unreachable. Generated by a KS when reac GDOI MIB Limitations The GDOI MIB contains only objects that are listed in RFC 3547 and does not contain objects for functionality specific to the Cisco implementation of GDOI. This functionality includes: - ve key servers Cooperati GM ACLs - only SAs - Receive - open - close/fail - Fail - Crypto map objects - - Other Cisco GETVPN specific features of Page 194 220 © 2018 Cisco Systems, Inc. Cisco Confidential/Proprietary GETVPN Design and Implementation Guide

195 5.5.1 SNMP Polling SNMP is an application - layer communication protocol that allows network devices to exchange management mation. Through SNMP, network administrators can manage network performance, find and solve infor network problems. GET VPN currently does not have support GET VPN related SNMP MIB objects. However, SNMP polling can poll other objects which can be used for track ing device performance. SNMP polling tools can be used that periodically poll the interesting objects and many of these tools also provide plotting functionality that allows network administrators to analyze performance data collected for a period of time. Table 7 lists some of the SNMP objects that can be used to monitor GET VPN device performance. The http://www.cisco.com OIDs of the SNMP objects can be obtained using the ―SNMP Object Navigator‖ tool at SNMP Objects Us Table 8. ed for SNMP Polling Description SNMP Object cpmCPUTotal1min The overall CPU busy percentage in the last minute cpmCPUTotal5min The overall CPU busy percentage in the last five minutes ciscoMemoryPoolUsed y in use by applications on the The number of bytes from the memory pool currentl managed device ciscoMemoryPoolFree The number of bytes from the memory pool that are currently unused on the managed device. Note that the sum of ciscoMemoryPoolUsed and ciscoMemoryPoolFree is the total the pool. amount of memory in cikeGlobalActiveTunnels 1 IKE Tunnels (Useful for KS) The number of currently active IPsec Phase - cipSecGlobalActiveTunnels 2 Tunnels (Useful for GMs) - The total number of currently active IPsec Phase Page 195 of 220 © 2018 Cisco Systems, Inc. Cisco Confidential/Proprietary GETVPN Design and Implementation Guide

196 SNMP plots to analyze GET VPN network behavior. The following sections describe how to use Normal Behavior 5.5.1.1 In a stable state, a KS maintains active IKE SAs for each COOP KS. For example, if there are four KSs, each KS has three IKE SAs in the GDOI_IDLE state. obtained by SNMP polling the KS. In case of four COOP KSs, each KS Figure 44 shows a sample plot maintains 3 IKE tunnels. IKE Tunnels – SNMP Polling: Steady State Figure 46 . Because a KS is busy only at registration time or during rekeys, KS CPU use stays close to 0%. CPU SNMP Polling: Steady state Figure 47. – Note: A CPU spike is seen at registration time and during rekey, as shown in Table 2. 5.5.1.2 COOP KS Failure In case of COOP server failure, the number of SAs goes down, indicating a communication loss with one or m ore of COOP KSs. Figure 46 shows that at time 10:30, an IKE SA expired at KS1, indicating that the KS lost reachability to a COOP servers. At time 10:50, all IKE SAs are reestablished, indicating that all lost KSs are back up. Further troubleshooting using syslog messages and show commands can help troubleshoot the network problems. of Page 196 220 © 2018 Cisco Systems, Inc. Cisco Confidential/Proprietary GETVPN Design and Implementation Guide

197 220 197 of Page © 2018 Cisco Systems, Inc. Cisco Confidential/Proprietary GETVPN Design and Implementation Guide

198 Figure 48. SNMP Polling: COOP KS Failure 5.5.1.3 Registration Burst under failure conditions, a burst of IKE sessions can be seen at If all GMs must reregister at a KS t he KS. Under such circumstances, the SNMP plot for IKE tunnels at the KS look like that in Figure 47. The plot shows that at around 12:00 pm, all GMs (more than 800) reregistered to the KS. S, the IKE sessions were Because GMs do not need to maintain active IKE sessions with the K cleared after a configured time. SNMP Polling: Burst of IKE Registrations at a KS Figure 49. of Page 198 220 © 2018 Cisco Systems, Inc. Cisco Confidential/Proprietary GETVPN Design and Implementation Guide

199 Appendix A. Complete Configurations for Section 2 A.1 Using Pre - Shared Keys A.1.1 Key Server Configuration ! hostname Primar y_K S ! crypto isakmp policy 10 encr aes 256 14 group authentication pre - share crypto isakmp key cisco address 192.168 .1.9 crypto isakmp key cisco address 192.168 .1.13 crypto isakmp key cisco address 172.18.5.2 ! sp trans e - set mygdoi - crypto ipsec transform - hmac - 256 sha - aes esp ! getvpn crypto ipsec profile gdoi - - profile set security - association lifetime seconds 7200 trans - set mygdoi - set transform ! crypto gdoi group getvpn identity number 1234 server local rekey retransmit 10 number 2 export rekey authenti cation mypubkey rsa getvpn - - general rekey transport unicast sa ipsec 1 - getvpn profile gdoi - profile match address ipv4 199 - replay time window size 5 of 220 Page 199 © 2018 Cisco Systems, Inc. Cisco Confidential/Proprietary GETVPN Design and Implementation Guide

200 172.16.4.2 address ipv4 redundancy local priority 100 5.2 peer address ipv4 172.18. ! interface FastEthernet0/1 description Outside Interface to PE 0 . 0 255.255. 172.16.4.2 ip address discovery - ip nbar protocol ip flow ingress load interval 30 - duplex auto speed auto ! 172.16.1.1 ip route 0.0.0.0 0.0.0.0 ! access - list 199 remark A CL Policies to be pushed to GMs access - list 199 permit ip 10.1.0.0 0.0.255.255 10.1.0.0 0.0.255.255 A.1.2 Cooperative Server ! hostname COOP_K S ! crypto isakmp policy 10 256 encr aes 14 group authentication pre - share crypto isakmp key cisco address 172. 16.4.2 crypto isakmp key cisco address 192.168 .1.9 crypto isakmp key cisco address 192.168 .1.13 ! sha 256 - hmac aes esp trans esp - - crypto ipsec transform - set mygdoi - ! - crypto ipsec profile gdoi getvpn - profile of Page 200 2 20 © 2018 Cisco Systems, Inc. Cisco Confidential/Proprietary GETVPN Design and Implementation Guide

201 set security - association lifetime seconds 7200 trans set mygdoi - - t transform se ! crypto gdoi group getvpn identity number 1234 server local rekey retransmit 10 number 2 export rekey authentication mypubkey rsa getvpn - - general rekey transport unicast sa ipsec 1 - getvpn - profile profile gdoi tch address ipv4 199 ma - replay time window size 5 172.18.5.2 address ipv4 redundancy local priority 75 peer address ipv4 172.16.4.2 ! interface FastEthernet0/1 description Outside interface to PE 0 . 255.255. 172.18.5.2 ip address 0 duplex auto speed auto type rj45 - media no negotiation auto ! 172.18.1.1 ip route 0.0.0.0 0.0.0.0 ! list 199 remark ACL Policies to be pushed to authenticated group - access members list 199 permit ip 10.1.0.0 0.0.255.255 10.1.0.0 0.0.255.255 - access Configuration A.1.3 Group Member ! of Page 201 220 © 2018 Cisco Systems, Inc. Cisco Confidential/Proprietary GETVPN Design and Implementation Guide

202 hostname GroupMember 1 - ! crypto isakmp policy 10 256 encr aes 14 group - share authentication pre crypto isakmp key cisco address 172.16.4.2 172.18.5.2 crypto isakmp key cisco address ! crypto gdoi group getvpn identity number 1234 172.16.4.2 r address ipv4 serve 172.18.5.2 server address ipv4 ! crypto map getvpn map 10 gdoi - set group getvpn ! interface FastEthernet0/0 description Inside interface ip address 10.1.11.1 255.255.255.0 ! interface FastEthernet0/1 face to PE description Outside inter ip address .1.9 255.255.255.252 192.168 ip flow ingress - interval 30 load duplex auto speed auto crypto map getvpn map - ! router bgp 1111 no synchronization - neighbor - bgp log changes of Page 202 220 © 2018 Cisco Systems, Inc. Cisco Confidential/Proprietary GETVPN Design and Implementation Guide

203 network 10.1.11.0 mask 255.255.255.0 .1.8 mask 255.255.255.252 network 192.168 neighbor as 1000 - .1.10 remote 192.168 summary no auto - A.2 Using Public Key Infrastructure (PKI) A.2.1 Key Server Configuration ! S hostname Primary_K ! crypto pki trustpoint GETVPN enrollment url http:// :80 172.16.1.2 - subject name OU =GETVPN revocation - check none enroll 70 auto - rsakeypair pkiPKS ! crypto pki certificate chain GETVPN certificate 70 certificate ca 01 ! crypto isakmp policy 10 encr aes 256 group 14 authentication rsa - sig ! - - hmac - crypto ipsec transform - set mygdoi - trans e sp 256 aes esp sha ! - profile - getvpn crypto ipsec profile gdoi - set security 7200 association lifetime seconds - set mygdoi - trans set transform ! crypto gdoi group getvpn identity number 1234 of Page 203 220 © 2018 Cisco Systems, Inc. Cisco Confidential/Proprietary GETVPN Design and Implementation Guide

204 server local rekey retransmit 10 number 2 general - export - ion mypubkey rsa getvpn rekey authenticat rekey transport unicast sa ipsec 1 - profile gdoi getvpn - profile match address ipv4 199 replay time window - size 5 172.16.4.2 address ipv4 redundancy local priority 100 172.18.5.2 peer address ipv4 ! ace FastEthernet0/1 interf description Outside Interface to PE 172.16.4.2 ip address 0 . 255.255. 0 - discovery ip nbar protocol ip flow ingress load - interval 30 duplex auto speed auto ! 172.16.1.1 ip route 0.0.0.0 0.0.0.0 ! - to be pushed to GMs access list 199 remark ACL Policies list 199 permit ip 10.1.0.0 0.0.255.255 10.1.0.0 0.0.255.255 - access A.2.2 Cooperative Server ! S hostname COOP_K ! crypto pki trustpoint GETVPN :80 172.16.1.2 enrollment url http:// subject name OU=GETVPN - of Page 204 220 © 2018 Cisco Systems, Inc. Cisco Confidential/Proprietary GETVPN Design and Implementation Guide

205 - revocation check none - auto en roll 70 rsakeypair pkiCOOP ! crypto pki certificate chain GETVPN certificate 6F certificate ca 01 ! crypto isakmp policy 10 256 encr aes 14 group authentication rsa - sig ! - sha trans esp - - hmac crypto ipsec transform - set mygdoi - aes esp ! profile - file gdoi crypto ipsec pro getvpn - set security - association lifetime seconds 7200 set mygdoi set transform - - trans ! crypto gdoi group getvpn identity number 1234 server local rekey retransmit 10 number 2 export - rekey authentication mypubkey rsa getvpn general - rekey transport unicast sa ipsec 1 getvpn profile gdoi - profile - match address ipv4 199 size 5 - replay time window address ipv4 172.18.5.2 redundancy local priority 75 172.16.1.2 peer address ipv4 of Page 205 220 © 2018 Cisco Systems, Inc. Cisco Confidential/Proprietary GETVPN Design and Implementation Guide

206 ! interface FastEthernet0/1 description Outside interface to PE 0 . 255.255. 172.18.5.2 ip address 0 duplex auto speed auto type rj45 - media no negotiation auto ! .1 172 ip route 0.0.0.0 0.0.0.0 .1. 8 1 ! list 199 remark ACL Policies to be pushed to authenticated group - access members 99 permit ip 10.1.0.0 0.0.255.255 10.1.0.0 0.0.255.255 list 1 - access A.2.3 Group Member Configuration ! hostname GroupMember - 1 ! crypto pki trustpoint GETVPN enrollment url http:// :80 172.16.1.2 subject - name OU=GETVPN check none - revocation auto enroll 70 - pkiGM1 rsakeypair ! crypto pki certificate chain GETVPN certificate 6E certificate ca 01 ! crypto isakmp policy 10 256 encr aes 14 group of Page 206 220 © 2018 Cisco Systems, Inc. Cisco Confidential/Proprietary GETVPN Design and Implementation Guide

207 - authentication rsa sig ! crypto gdoi group getvpn identity number 1234 172.16.1.2 server address ipv4 172.18.5.2 server address ipv4 ! - map 10 gdoi crypto map getvpn set group getvpn ! interface FastEthernet0/0 description LAN interface ip address 10.1.11.1 255.255.255.0 ip tcp adjust mss 1360 - ! interface FastEthernet0/1 description WAN interface to PE .9 255.255.255.252 ip address 10.1.1 interval 30 duplex auto ip flow ingress load - speed auto crypto map getvpn - map ! router bgp 1111 no synchronization - changes - bgp log neighbor network 10.1.11.0 mask 255.255.255.0 network 10.1.1.8 mask 255.255.255.252 as 1000 - 1.10 remote neighbor 10.1. no auto - summary A.3 IOS Certificate Authority A.3.1 Configuration ! crypto pki server GETVPN of Page 207 220 © 2018 Cisco Systems, Inc. Cisco Confidential/Proprietary GETVPN Design and Implementation Guide

208 database level names - name CN = GET, OU = NSITE, O = CISCO, L = RTP, ST = NC issuer grant auto lifetime crl 4 lifetime certificate 730 li fetime ca - certificate 1825 database url flash: ! crypto pki trustpoint GETVPN check crl - revocation rsakeypair GETVPN ! crypto pki certificate chain GETVPN certificate ca 01 A.3.2 Verification mand The CA configuration can be verified using the following com DGVPN CA# sh crypto pki server - Certificate Server GETVPN: Status: enabled State: enabled Server‟s configuration is locked (enter "shut" to unlock it) Issuer name: CN = GET, OU = NSITE, O = CISCO, L = RTP, ST = NC FAADEFD4 E205EA6B CA cert fingerprint: FFD61C4E F12676BA Granting mode is: auto Last certificate issued serial number: 0x70 CA certificate expiration timer: 18:11:56 EDT Jun 10 2016 2012 CRL NextUpdate timer: 14:19:08 est Feb 4 Current primary storage dir: flash: t name data written as .cnm subjec - Database Level: Names of Page 208 220 © 2018 Cisco Systems, Inc. Cisco Confidential/Proprietary GETVPN Design and Implementation Guide

209 - A.4 G IKEv2 Configuration Using PKI A.4.1 Key Server Configuration hostname Primary_KS ! crypto pki trustpoint GETVPN enrollment url http://172.16.1.2:80 subject name OU=GETVPN - - revocation check none enroll 7 auto - 0 rsakeypair pkiGM1 ! PROPOSAL crypto ikev2 proposal IKE2 - encryption aes 256 - - cbc integrity sha256 group 19 ! POLICY - crypto ikev2 policy IKE2 match fvrf any PROPOSAL - proposal IKE2 ! crypto ikev2 profile IKE2 PROFILE - match identity remote email sov [email protected] identity local key - id sovm sig authentication local rsa - authentication remote rsa - sig pki trustpoint GETVPN ! - aes esp - crypto ipsec transform set TEK esp - hmac sha - mode tunnel ! IKEv2 crypto ipsec profile IPSEC - PROFILE - G - - set security ciation lifetime seconds 7200 asso set transform set TEK - PROFILE profile IKE2 - set ikev2 - GROUP - crypto gkm group GKM identity number 130 server local no gdoi - gikev2 IKE2 PROFILE rekey algorithm aes 256 of Page 209 220 © 2018 Cisco Systems, Inc. Cisco Confidential/Proprietary GETVPN Design and Implementation Guide

210 rekey sig - hash algorithm sha512 rekey retran smit 40 number 3 general - rekey authentication mypubkey rsa getvpn - export rekey transport unicast sa ipsec 1 IKEv2 - profile IPSEC - PROFILE - G - match address ipv4 get acl - size 5 replay time window no tag address ipv4 10.1.10.1 redunda ncy local priority 100 peer address ipv4 10.1.20.1 protocol version optimize interface FastEthernet0/1 description Outside Interface to PE ip address 10.1.10.1 255.255.0.0 - access - list get acl remark ACL Policies to be pushed to GMs acces acl deny esp any any - list get - s acl deny tcp any any eq tacacs - - access list get access list get - acl deny tcp any eq tacacs any - access - list get - acl deny tcp any any eq ssh - access - list get acl deny tcp any eq ssh any access list get - acl deny tcp any any eq bgp - access - list get - acl deny tcp any eq bgp any - acl deny ospf any any access - list get - list get - access acl deny eigrp any any - list get - acl deny pim any 224.0.0.0 0.0.0.255 access access - list get - acl deny udp any eq isakmp any eq isakmp - l deny udp any any eq 848 ac list get - access - acl permit ip 10.2.0.0 0.0.255.255 10.2.0.0 0.0.255.255 access - list get A.4.2 COOP Key Server Configuration hostname COOP_KS ! crypto pki trustpoint GETVPN enrollment url http://172.16.1.2:80 - name OU=GETVPN subject heck none c - revocation - auto enroll 70 of Page 210 220 © 2018 Cisco Systems, Inc. Cisco Confidential/Proprietary GETVPN Design and Implementation Guide

211 rsakeypair pkiGM1 ! crypto ikev2 proposal IKE2 - PROPOSAL encryption aes 256 - cbc - integrity sha256 group 19 ! - crypto ikev2 policy IKE2 POLICY match fvrf any PROPOSAL proposal IKE2 - ! crypto ikev2 profile IKE2 - PROFILE match i dentity remote email [email protected] identity local key - id sovm authentication local rsa - sig authentication remote rsa - sig pki trustpoint GETVPN ! - sha - hmac set TEK esp - - aes esp crypto ipsec transform mode tunnel ! IKEv2 - PROFILE - G - crypto ipsec profile IPSEC set security - association lifetime seconds 7200 set transform - set TEK PROFILE set ikev2 - profile IKE2 - GROUP - crypto gkm group GKM identity number 130 server local no gdoi gikev2 IKE2 PROFILE - rekey algorithm aes 256 - rekey sig hash algorit hm sha512 rekey retransmit 40 number 3 general - export rekey authentication mypubkey rsa getvpn - rekey transport unicast sa ipsec 1 PROFILE - G - IKEv2 profile IPSEC - acl match address ipv4 get - size 5 - replay time window no tag pv4 10.1.20.1 address i of Page 211 220 © 2018 Cisco Systems, Inc. Cisco Confidential/Proprietary GETVPN Design and Implementation Guide

212 redundancy local priority 75 peer address ipv4 10.1.20.1 protocol version optimize interface FastEthernet0/1 description Outside Interface to PE ip address 10.1.20.1 255.255.0.0 be pushed to GMs acl remark ACL Policies to - list get - access - list get - acl deny esp any any access access - list get - acl deny tcp any any eq tacacs list get acl deny tcp any eq tacacs any - access - - list get - acl deny tcp any any eq ssh access access - list get - acl deny tcp any eq ssh any - acl deny tcp any any eq bgp access - list get acl deny tcp any eq bgp any list get - access - acl deny ospf any any - list get - access acl deny eigrp any any - list get - access - list get - acl deny pim any 224.0.0.0 0.0.0.255 access access - list get - acl deny udp any eq isakmp any eq is akmp - - access list get acl deny udp any any eq 848 access - list get - acl permit ip 10.2.0.0 0.0.255.255 10.2.0.0 0.0.255.255 A.4.3 Group Member Configuration 1 hostname GroupMember - ! crypto pki trustpoint GETVPN enrollment url http://172.16.1.2:80 me OU=GETVPN na - subject revocation - check none enroll 70 - auto rsakeypair pkiGM1 ! crypto ikev2 proposal IKE2 - PROPOSAL 256 - - encryption aes cbc integrity sha256 group 19 ! POLICY - crypto ikev2 policy IKE2 match fvrf any PROPOSAL - proposal IKE2 of Page 212 220 © 2018 Cisco Systems, Inc. Cisco Confidential/Proprietary GETVPN Design and Implementation Guide

213 ! crypto ikev2 pr PROFILE - ofile IKE2 id sovm - match identity remote key identity local email [email protected] authentication local rsa - sig sig - authentication remote rsa pki trustpoint GETVPN ! GROUP - crypto gkm group GKM identity number 130 server address ipv4 10.1.10.1 server address ipv4 10.1.20.1 client protocol gikev2 IKE2 PROFILE - client registration interface Ethernet0/0 ! crypto map GETVPN_MAP 10 gdoi GROUP set group GKM - ! interface Ethernet0/0 .255.0 ip address 10.1.1.101 255.255 crypto map GETVPN_MAP of Page 213 220 © 2018 Cisco Systems, Inc. Cisco Confidential/Proprietary GETVPN Design and Implementation Guide

214 Steps to upgrade Key Servers and Group Members App endix B. This section focusses on the steps to upgrade the IOS and/or IOS - XE versions on the Key Servers and of these steps is to minimize changes in the TEK and Group Members in a GETVPN network. The intent K EK during the upgrades of the Key Servers. Setting the TEK lifetime to 7200 seconds (and KEK 86400 onds ), would give a two hour window to upgrade the K ey Servers where no key changes are needed. sec If an upgrade of both Key Servers and Group Members is r equired, it is recommended to start with the Key Servers and then upgrade the Group Members. Steps to u p grade the Key Servers erver . S 1 . Upgrade a Secondary K ey . Wait for the COOP 2 S is upgraded. erver ey election to complete till the next Secondary K 3 . R epeat the above steps to upgrade all Secondary K ey S erver s in the COOP network. s and should reboot synchronize with the existing erver. They S ey rimary K P The S econdary K ey S erver sh . erver S ould resume their previous role as Secondary K ey ey . The Primary Key Server upgrade will force one of the Secondary e the Primary K erver S . Finally, upgrad 4 Key Servers to be promoted to Primary status. Once the previous Primary reboots, it should assume the role of a Secondary Key Server. he Key Server upgrades when there is plenty of time remaining in both the It is recommended to complete t KEK and TEK. of Page 214 220 © 2018 Cisco Systems, Inc. Cisco Confidential/Proprietary GETVPN Design and Implementation Guide

215 Appendix C. Steps to change RSA Keys on Key Servers vers, it is recommended to do so using the following steps. the RSA keys on the Key Ser While changing sure a smooth transition from the old keys to the new with traffic disruption. This will en no remaining with the KEK and TEK on the Key Servers. This can be 1. Verify that there is sufficient time STEP checked using the command ― ‖. The intent is to complete the change on show crypto gdoi ks policy If it is not possible to complete all the Key Servers with sufficient time remaining in both the KEK and TEK. the RSA key change within the remaining KEK/TEK lifetime, it is recommended to wait for a rekey before starting the process (steps 2 thru 4 below) . with the Primary KS. STEP 2. Remove the RSA keys on all the Key Servers starting show crypto gdoi ks policy a. Use the command ̳ ‘ to find the RSA key associated with the gdoi group. y zeroize rsa ‘ to delete the RSA key from each of b. Use the command ̳ crypto ke the Key Servers 3. Generate an exportable RSA key using the following command on the Primary Key Server: STEP - (config)#crypto key generate rsa modulus 2048 label KS Primary exportable Secondary 4. Export the RSA key generated on the Primary Key Server to all TEP S Key Servers. Here is a can be output of the export and import process using the console option. Instead of console the key s sample to exported and imported from a TFTP location also. Export the RSA key on the Primary Key Server: export rsa (config)#crypto key Primary - KS code> % Key name: Usage: General Purpose Key Key data: BEGIN PUBLIC KEY ----- ----- KBgQCuKbSROW7eSqxC+IjB0ipplVkT MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQ .. NtSRSR51ooWQW5CXRwIDAQAB ----- ----- END PUBLIC KEY BEGIN RSA PRIVATE KEY ----- ----- Proc - Type: 4,ENCRYPTED Info: DES - - EDE3 - CBC,B2CE8D823EE52FDC DEK Zi82W/lX3u0WiHN0ezi6qH5Jeo1baptdqzLlVk2jioAyZabWJqc7+svFY+DJ8rT+ ... p3dHnQSB aLu1pH3YI9gebQhMgqH6Ie00ucEYVl4/jArzUjifjdCvkQ== ----- END RSA PRIVATE KEY ----- : each of the Secondary Key Servers Import the RSA key on of Page 215 220 © 2018 Cisco Systems, Inc. Cisco Confidential/Proprietary GETVPN Design and Implementation Guide

216 " is same as the one Pass code Execute the below command on the configuration prompt of the router. " used to export the k ey. KS(config)#crypto key import rsa - Secondary pem terminal % Enter PEM - formatted public General Purpose key or certificate. % End with a blank line or "quit" on a line by itself. rt. Paste marked the hexadecimel information the lines quit formatted encrypted private General Purpose key. - % Enter PEM % End with "quit" on a line by itself. the hexadecimel quit ! t ey he next scheduled rekey from the Primary K STEP 5. Now will be rejected by the Group Members erver S This is the expected behavior. Following is a syslog message still have the old RSA keys. ey since th di splayed on the Group Member when this occurs: GM1# IKMP_MODE_FAILURE: Processing of GDOI mode *Jun 5 18:20:22.383: %CRYPTO - 6 - failed with peer at 10.0.8.1 - , KSs register with their just before the expiry of their TEK/KEK. Aft er the will re GMs STEP 6. As a result registration, the Group Members should have the latest policies and keys (including the new RSA keys). of Page 216 220 © 2018 Cisco Systems, Inc. Cisco Confidential/Proprietary GETVPN Design and Implementation Guide

217 Enhancements Appendix D. Recent Features and releases The following table shows the recent GETVPN features and their corresponding . Feature Name IOS Version XE Version IOS - GETVPN Key Server Initial Initial Release XE 3.9S VRF Aware GM XE 3.12 15(0)1M GETVPN GM Removal & Policy Trigger XE 3.8S 15.2(1)T GDOI MIB Support 15.2(1)T XE 3.8S GETVPN IPv6 Dataplane Support 15.2(3)T 15.3(1)S/XE 3.8S - G B support ETVPN Suite 15.2(4)M XE 3.9S 15.3(2)S/XE3.9S GETVPN support of IPsec Inline Tagging for 15.3(2)T Cisco TrustSec 15.3(2)S/XE3.9S GETVPN Resiliency 15.3(2)T Long SA Lifetime Up Rekey - Periodic Reminder Sync Pre Positioned Rekey - Debugging and Trace GETVPN ability 15.3(2)T 15.3(2)S/XE3.9S enhancements GM Error Recovery 15.3(3)M 15.3(3)S / XE 3.10S GETVPN Certificate Revocation List (CRL) 15.3(3)S/XE 3.10S 15.3(3)M Checking GDOI / IKE Separation 15.4(1)T 15.4(1)S/XE 3.11S GETVPN Routing Awar eness for BGP 15.4(3)M 15.4(3)S/XE 3.13S GETVPN GDOI Bypass 15.4(3)S/XE 3.13S 15.4(3)M ASR9k Specific N/A N/A - IKEv2 G 15.5(1)S/XE 3.14S 15.5(1)T 8K GM Scale Improvements 15.5(1)T 15.5(1)S/XE 3.14S (KS only) IP y) - for Interoperability (KS onl - D3P & ID ACK 15.5(1)T 15.5(1)S/XE 3.14S IP - D3P support on GM N/A IOS XE Fuji 16.7.1 profile based GIKEv2 authorization IKEv2 N/A IOS XE Fuji 16.8.1 support GETVPN Policy Change Rekey Enhancement IOS XE Fuji 16.8.1 N/A (ASR1k Specific) - * Tentative release of Page 217 220 © 2018 Cisco Systems, Inc. Cisco Confidential/Proprietary GETVPN Design and Implementation Guide

218 ndix Appe E . Abbreviations and Acronyms . Some The following table lists some common abbreviations and acronyms used to discuss GETVPN common abbreviations and acronyms are not expanded in the text, but are included here for reference. an asterisk. Such terms are marked with Abbreviation or Acronym Expansion Triple Data Encryption Standard (DES) 3DES authentication, authorization, and accounting AAA access control list ACL Advanced Encryption Standard AES CA certificate authority CE customer edge (device) command line interface CLI CM Central Manager COOP Cooperative (Protocol) class of service CoS customer premises equipment CPE DC data center Dynamic Host Configuration Protocol DHCP* Dynamic Multipoint VPN DMVPN dead peer detection DPD Diffe rentiated Services Code Point DSCP DSL digital subscriber line subscriber digital DSLAM line access multiplexer FIB Forwarding Information Base FWSM Firewall Switching Module (6500/7600) Group Domain Of Interpretation GDOI GETVPN VPN Group Encrypted Transport GM group member Generic Routing Encapsulation GRE GUI* graphical user interface HA high availability Health Insurance Portability and Accountability Act HIPAA HSRP Hot Standby Router Protocol ICMP Internet Control Messaging Protocol et Key Exchange Intern IKE IP* Internet Protocol IP security IPsec Internet service provider ISP* key encryption key KEK key server KS L2TP Layer 2 Tunneling Protocol of Page 218 220 © 2018 Cisco Systems, Inc. Cisco Confidential/Proprietary GETVPN Design and Implementation Guide

219 Abbreviation or Acronym Expansion MAC* Media Access Control MPLS Multiprotocol Label Switching MSDP y Protocol Multicast Source Discover MTU maximum transmission unit network address translation NAT NTP Network Time Protocol OSPF* Open Shortest Path First PE provider edge performance routing PfR PKI public key infrastructure shared keys - pre PSK quality of service QoS SA security association (IPsec) SADB security association database server load balancing SLB SNMP* Simple Network Management Protocol service provider SP TBAR replay - based anti - time TEK traffic encryption key TFTP Trivial File Transfer Protocol U ser Datagram Protocol UDP virtual IP address VIP virtual local area network VLAN* voice over IP VoIP* VPN virtual private network virtual routing and forwarding VRF VPN Services Adapter VSA VTI Virtual Tunnel Interface Wide Area Application Servi ces WAAS of Page 219 220 © 2018 Cisco Systems, Inc. Cisco Confidential/Proprietary GETVPN Design and Implementation Guide

220 4 0 - 10/18 Printed in USA C 07 - 584888 Page 220 of 220 © 2018 Cisco Systems, Inc. Cisco Confidential/Proprietary GETVPN Design and Implementation Guide

Related documents