Security and VPN Configuration Guide, Cisco IOS XE 17.x

The documentation set for this product strives to use bias-free language. For the purposes of this documentation set, bias-free is defined as language that does not imply discrimination based on age, disability, gender, racial identity, ethnic identity, sexual orientation, socioeconomic status, and intersectionality. Exceptions may be present in the documentation due to language that is hardcoded in the user interfaces of the product software, language used based on RFP documentation, or language that is used by a referenced third-party product. Learn more about how Cisco is using Inclusive Language.

• Preface
• Authentication Authorization and Accounting
  • Configuring Authentication
  • RADIUS Change of Authorization
  • Message Banners for AAA Authentication
  • AAA-Domain Stripping at Server Group Level
  • AAA Double Authentication Secured by Absolute Timeout
  • Throttling of AAA RADIUS Records
  • RADIUS Packet of Disconnect
  • AAA Authorization and Authentication Cache
  • Configuring Authorization
  • Configuring Accounting
  • AAA-SERVER-MIB Set Operation
  • Per VRF AAA
  • AAA Support for IPv6
  • TACACS+ over IPv6
  • AAA Dead-Server Detection
  • Login Password Retry Lockout
  • MSCHAP Version 2
  • AAA Broadcast Accounting-Mandatory Response Support
  • Password Strength and Management for Common Criteria
  • Secure Reversible Passwords for AAA
  • Reverse SSH Enhancements
  • Secure Copy
  • Secure Shell Version 2 Support
  • Secure Shell—Configuring User Authentication Methods
  • X.509v3 Certificates for SSH Authentication
  • SSH Algorithms for Common Criteria Certification
  • Secure Shell—Configuring SFTP Username and Password
  • IP Access List Overview
  • Creating an IP Access List and Applying It to an Interface
  • Creating an IP Access List to Filter IP Options, TCP Flags, Noncontiguous Ports
  • Configuring an FQDN ACL
  • Refining an IP Access List
  • IP Named Access Control Lists
  • Commented IP Access List Entries
  • Standard IP Access List Logging
  • IP Access List Entry Sequence Numbering
  • Configuring Lock-and-Key Security (Dynamic Access Lists)
  • ACL IP Options Selective Drop
  • Displaying and Clearing IP Access List Data Using ACL Manageability
  • ACL Syslog Correlation
  • IPv6 Access Control Lists
  • IPv6 ACL Undetermined-Transport Support
  • Configuring Template ACLs
  • IPv6 Template ACL
  • IPv4 ACL Chaining Support
  • IPv6 ACL Chaining with a Common ACL
  • IPv6 ACL Extensions for Hop by Hop Filtering
  • Security (ACL) Enhancements
  • IPv6 Object Groups for ACLs
  • Configuring RADIUS
  • RADIUS for Multiple UDP Ports
  • AAA DNIS Map for Authorization
  • AAA Server Groups
  • Framed-Route in RADIUS Accounting
  • RFC-2867 RADIUS Tunnel Accounting
  • RADIUS Logical Line ID
  • RADIUS Route Download
  • RADIUS Server Load Balancing
  • RADIUS Server Reorder on Failure
  • RADIUS Separate Retransmit Counter for Accounting
  • RADIUS VC Logging
  • RADIUS Centralized Filter Management
  • RADIUS EAP Support
  • RADIUS Interim Update at Call Connect
  • RADIUS Tunnel Preference for Load Balancing and Fail-Over
  • RADIUS Attributes Overview and RADIUS IETF Attributes
  • RADIUS Vendor-Proprietary Attributes
  • RADIUS Vendor-Specific Attributes and RADIUS Disconnect-Cause Attribute Values
  • Connect-Info RADIUS Attribute 77
  • Encrypted Vendor-Specific Attributes
  • RADIUS Attribute 8 Framed-IP-Address in Access Requests
  • RADIUS Attribute 82 Tunnel Assignment ID
  • RADIUS Tunnel Attribute Extensions
  • RADIUS Attribute 66 Tunnel-Client-Endpoint Enhancements
  • RADIUS Attribute Value Screening
  • RADIUS Attribute 55 Event-Timestamp
  • RADIUS Attribute 104
  • RADIUS NAS-IP-Address Attribute Configurability
  • RADIUS Attribute 5 NAS-Port Format Specified on a Per-Server Group Level
  • Configuring TACACS
  • Per VRF for TACACS Servers
  • TACACS Attribute-Value Pairs
  • Overview of Cisco TrustSec
  • Cisco TrustSec SGT Exchange Protocol IPv4
  • TrustSec SGT Handling: L2 SGT Imposition and Forwarding
  • Prerequisites for Cisco TrustSec SGT Exchange Protocol IPv4
  • Enabling Bidirectional SXP Support
  • Cisco TrustSec Interface-to-SGT Mapping
  • Cisco TrustSec Subnet to SGT Mapping
  • Flexible NetFlow Export of Cisco TrustSec Fields
  • Cisco TrustSec SGT Caching
  • CTS SGACL Support
  • Accessing TrustSec Operational Data Externally
  • Access Node Control Protocol
  • Multiservice Activation in Access-Accept Message
  • Multiservice Activation and Deactivation in a CoA Message
  • IPv6 RA Guard
  • IPv6 Snooping
  • IPv6 DAD Proxy
  • IPv6 Neighbor Discovery Multicast Suppress
  • DHCP—DHCPv6 Guard
  • IPv6 Source Guard and Prefix Guard
  • IPv6 Destination Guard
  • IPv6 RFCs
  • WAN MACSEC and MKA Support Enhancements
  • MACsec Smart Licensing
  • Certificate-based MACsec Encryption
  • MACsec as a Service-An Encryption Solution
  • Cisco IOS XE PKI Overview
  • Deploying RSA Keys Within a PKI
  • Configuring Authorization and Revocation of Certificates in a PKI
  • Configuring Certificate Enrollment for a PKI
  • Setting Up Secure Device Provisioning for Enrollment in a PKI
  • PKI Credentials Expiry Alerts
  • Configuring and Managing a Certificate Server for PKI Deployment
  • Storing PKI Credentials
  • Source Interface Selection for Outgoing Traffic with Certificate Authority
  • PKI Trustpool Management
  • PKI Split VRF in Trustpoint
  • EST Client Support
  • Configuring Route Processor Redundancy for PKI
  • Zone-Based Policy Firewalls
  • Zone-Based Policy Firewall IPv6 Support
  • VRF-Aware Cisco IOS XE Firewall
  • Layer 2 Transparent Firewalls
  • Nested Class Map Support for Zone-Based Policy Firewall
  • Zone Mismatch Handling
  • Configuring Firewall Stateful Interchassis Redundancy
  • Firewall Box to Box High Availability Support for Cisco CSR1000v Routers
  • Interchassis Asymmetric Routing Support for Zone-Based Firewall and NAT
  • Box-to-Box High Availability Support for IPv6 Zone-Based Firewalls
  • Firewall Stateful Inspection of ICMP
  • LISP and Zone-Based Firewalls Integration and Interoperability
  • Application Aware Firewall
  • Firewall Support of Skinny Client Control Protocol
  • IPv6 Zone-Based Firewall Support over VASI Interfaces
  • Configuring the VRF-Aware Software Infrastructure
  • FTP66 ALG Support for IPv6 Firewalls
  • Protection Against Distributed Denial of Service Attacks
  • Configuring Firewall Resource Management
  • IPv6 Firewall Support for Prevention of Distributed Denial of Service Attacks and Resource Management
  • Configurable Number of Simultaneous Packets per Flow
  • Firewall High-Speed Logging
  • TCP Reset Segment Control
  • Loose Checking Option for TCP Window Scaling in Zone-Based Policy Firewall
  • Enabling ALGs and AICs in Zone-Based Policy Firewalls
  • Configuring Firewall TCP SYN Cookie
  • Object Groups for ACLs
  • Cisco Firewall-SIP Enhancements ALG
  • MSRPC ALG Support for Firewall and NAT
  • Sun RPC ALG Support for Firewalls and NAT
  • Zone-Based Firewall ALG and AIC Conditional Debugging and Packet Tracing Support
  • ALG—H.323 vTCP with High Availability Support for Firewall and NAT
  • SIP ALG Hardening for NAT and Firewall
  • SIP ALG Resilience to DoS Attacks
  • Configuring Security for VPNs with IPsec
  • IPsec Virtual Tunnel Interfaces
  • Session Initiation Protocol Triggered VPN
  • Deleting Crypto Sessions of Revoked Peer Certificates
  • Crypto Conditional Debug Support
  • IPv6 over IPv4 GRE Tunnel Protection
  • RFC 430x IPsec Support
  • Cisco Firepower Threat Defense for ISR
  • Snort IPS
  • Web Filtering
  • Configuring Multi-Tenancy for Unified Threat Defense
  • Cisco Umbrella Integration
  • Cisco IOS Login Enhancements-Login Block
  • Configuring Security with Passwords, Privileges, and Logins
  • Role-Based CLI Access
  • Information About Secure Storage
  • AutoSecure
  • Configuring Kerberos
  • Lawful Intercept Architecture
  • LI Support for IPoE Sessions
  • Image Verification
  • IPsec Anti-Replay Window Expanding and Disabling
  • Pre-Fragmentation for IPsec VPNs
  • Invalid Security Parameter Index Recovery
  • IPsec Dead Peer Detection Periodic Message Option
  • IPsec NAT Transparency
  • IPsec Extended Sequence Number
  • DF Bit Override Functionality with IPsec Tunnels
  • IPsec Security Association Idle Timers
  • IPv6 IPsec Quality of Service
  • IPv6 Virtual Tunnel Interface
  • IP Security VPN Monitoring
  • IPsec and IKE MIB Support forCisco VRF-Aware IPsec
  • IPsec SNMP Support
  • IPsec VPN Accounting
  • IPsec Usability Enhancements
  • Reverse Route Injection
  • IPsec VPN High Availability Enhancements
  • IPsec Preferred Peer
  • Real-Time Resolution for IPsec Tunnel Peer
  • Configuring Internet Key Exchange for IPsec VPNs
  • Call Admission Control for IKE
  • Certificate to ISAKMP Profile Mapping
  • Encrypted Preshared Key
  • Distinguished Name Based Crypto Maps
  • IPsec and Quality of Service
  • VRF-Aware IPsec
  • IKE Initiate Aggressive Mode
  • Dynamic Multipoint VPN
  • IPv6 over DMVPN
  • DMVPN Configuration Using FQDN
  • DMVPN-Tunnel Health Monitoring and Recovery Backup NHS
  • DMVPN Tunnel Health Monitoring and Recovery
  • DMVPN Event Tracing
  • NHRP MIB
  • DMVPN Dynamic Tunnels Between Spokes Behind a NAT Device
  • Sharing IPsec with Tunnel Protection
  • Per-Tunnel QoS for DMVPN
  • Configuring TrustSec DMVPN Inline Tagging Support
  • Spoke-to-Spoke NHRP Summary Maps
  • BFD Support on DMVPN
  • DMVPN Support for IWAN
  • Configuring MPLS over DMVPN
  • DHCP Tunnels Support
  • Per-Tunnel QoS Support for Multiple Policy Maps (MPOL)
  • Introduction to FlexVPN
  • Configuring Internet Key Exchange Version 2
  • Configuring Quantum-Safe Encryption Using Postquantum Preshared Keys
  • Configuring the FlexVPN Server
  • Configuring the FlexVPN Client
  • Configuring FlexVPN Spoke to Spoke
  • Configuring IKEv2 Load Balancer
  • Configuring IKEv2 Fragmentation
  • Configuring IKEv2 Reconnect
  • Configuring MPLS over FlexVPN
  • Configuring IKEv2 Packet of Disconnect
  • Configuring IKEv2 Change of Authorization Support
  • Configuring Aggregate Authentication
  • Appendix: FlexVPN RADIUS Attributes
  • Appendix: IKEv2 and Legacy VPNs
  • Cisco Group Encrypted Transport VPN
  • GET VPN GM Removal and Policy Trigger
  • GDOI MIB Support for GET VPN
  • GET VPN Resiliency
  • GETVPN Resiliency GM - Error Detection
  • GETVPN CRL Checking
  • GET VPN Support with Suite B
  • GET VPN Support of IPsec Inline Tagging for Cisco TrustSec
  • GETVPN GDOI Bypass
  • GETVPN G-IKEv2
  • 8K GM Scale Improvement
  • GET VPN Interoperability
  • Perfect Forward Secrecy for GETVPN
  Find Matches in This Book Log in to Save Content Available Languages Download Options

  Book Title

  Security and VPN Configuration Guide, Cisco IOS XE 17.x

  Configuring Security for VPNs with IPsec

  • PDF - Complete Book (34.14 MB)PDF - This Chapter (1.35 MB) View with Adobe Reader on a variety of devices

  Results

  Updated: January 11, 2021

  Chapter: Configuring Security for VPNs with IPsec

  Chapter Contents
  • Configuring Security for VPNs with IPsec
  • Prerequisites for Configuring Security for VPNs with IPsec
  • Restrictions for Configuring Security for VPNs with IPsec
  • Information About Configuring Security for VPNs with IPsec
    • Supported Standards
    • Supported Encapsulation
    • IPsec Functionality Overview
      • IKEv1 Transform Sets
      • IKEv2 Transform Sets
      • About Transform Sets
      • Suite-B Requirements
      • Where to Find Suite-B Configuration Information
      • Creating Crypto Access Lists
        • What to Do Next
        • Restrictions
        • Configuring Transform Sets for IKEv1
          • What to Do Next
          • Transform Sets for IKEv2 Examples
          • What to Do Next
          • Information About Security Association Strength Enforcement
            • Overview
            • Supported Platforms for Security Association Strength Enforcement
            • Configuring Security Association Strength Enforcement
            • Example: Configuring Security Association Strength Enforcement
            • Creating Static Crypto Maps
              • Troubleshooting Tips
              • What to Do Next
              • Troubleshooting Tips
              • What to Do Next
              • Troubleshooting Tips
              • What to Do Next
              • Example: Configuring AES-Based Static Crypto Map

              Configuring Security for VPNs with IPsec

              This module describes how to configure basic IPsec VPNs. IPsec is a framework of open standards developed by the IETF. It provides security for the transmission of sensitive information over unprotected networks such as the Internet. IPsec acts at the network layer, protecting and authenticating IP packets between participating IPsec devices (“peers”), such as Cisco routers.

              Security threats, as well as the cryptographic technologies to help protect against them, are constantly changing. For more information about the latest Cisco cryptographic recommendations, see the Next Generation Encryption (NGE) white paper.

              Prerequisites for Configuring Security for VPNs with IPsec

              IKE Configuration

              You must configure Internet Key Exchange (IKE) as described in the module Configuring Internet Key Exchange for IPsec VPNs.

              If you decide not to use IKE, you must still disable it as described in the module Configuring Internet Key Exchange for IPsec VPNs.

              Ensure Access Lists Are Compatible with IPsec

              IKE uses UDP port 500. The IPsec encapsulating security payload (ESP) and authentication header (AH) protocols use protocol numbers 50 and 51, respectively. Ensure that your access lists are configured so that traffic from protocol 50, 51, and UDP port 500 are not blocked at interfaces used by IPsec. In some cases, you might need to add a statement to your access lists to explicitly permit this traffic.

              Restrictions for Configuring Security for VPNs with IPsec

              Cisco IPsec Policy Map MIB

              The MIB OID objects are displayed only when an IPsec session is up.

              Discontiguous Access Control Lists

              Crypto maps using access control lists (ACLs) that have discontiguous masks are not supported.

              Physical Interface and Crypto Map

              A crypto map on a physical interface is not supported, if the physical interface or the source IP is the source interface of a tunnel protection interface.

              NAT Configuration

              If you use Network Address Translation (NAT), you should configure static NAT so that IPsec works properly. In general, NAT should occur before the router performs IPsec encapsulation; in other words, IPsec should work with global addresses.

              Unicast IP Datagram Application Only

              IPsec can be applied to unicast IP datagrams only. Because the IPsec Working Group has not yet addressed the issue of group key distribution, IPsec does not currently work with multicasts or broadcast IP datagrams.

              IPSec SA Establishment

              There is a 10-second delay between IPSec SA creations for different ACEs in the crypto ACL

              Unsupported Interface Types

              • Crypto VPNs are not supported on the bridge domain interfaces (BDI).
              • Crypto maps are not supported on tunnel interface and port-channel interface. As an exception, crypto maps for GDOI are supported on tunnel interfaces.
              • Crypto maps are not supported on loopback interfaces.
              • If transport profile is enabled on a tunnel, crypto maps are not supported on the tunnel source interfaces.
              • Crypto maps are not supported on tunnel interface of MFR.
              • Crypto maps are not supported on Vlan interfaces
              • GetVPN crypto map is supported on port-channel interfaces.

              Information About Configuring Security for VPNs with IPsec

              Supported Standards

              Cisco implements the following standards with this feature:

              IPsec—IPsec is a framework of open standards that provides data confidentiality, data integrity, and data authentication between participating peers. IPsec provides these security services at the IP layer; IPsec uses IKE to handle negotiation of protocols and algorithms based on the local policy, and generate the encryption and authentication keys to be used by IPsec. IPsec can be used to protect one or more data flows between a pair of hosts, between a pair of security gateways, or between a security gateway and a host.

              Note	The term IPsec is sometimes used to describe the entire protocol of IPsec data services and IKE security protocols, and is also sometimes used to describe only the data services.

              Starting from Cisco IOS XE Bengaluru 17.6.x, configuring a weak crypto algorithm generates a warning, but the warning can be safely ignored and does not impact the working of the algorithms. The following example displays a warning message for a weak crypto algorithm:

              Device(config-ikev2-proposal)# group 5 %Warning: weaker dh-group is deprecated

              The following table lists all the weak algorithms.

              IKEv1

              IKEv2

              IPsec

              The component technologies implemented for IPsec include:

              Starting from Cisco IOS XE 17.11.1a, as part of security hardening and deprecation of weak ciphers, the options to configure DES, 3DES, MD5, and Diffie-Hellman (DH) groups 1, 2, and 5 are deprecated and are no longer supported. Instead, use AES, SHA, and DH Groups 14 or higher. Additionally, the esp-gmac transforms are also deprecated.

              If you want to continue using the weak ciphers, disable CSDL compliance on the device using the crypto engine compliance shield disable command, and reboot.

              • AES—Advanced Encryption Standard. A cryptographic algorithm that protects sensitive, unclassified information. AES is a privacy transform for IPsec and IKE and has been developed to replace DES. AES is designed to be more secure than DES. AES offers a larger key size, while ensuring that the only known approach to decrypt a message is for an intruder to try every possible key. AES has a variable key length—the algorithm can specify a 128-bit key (the default), a 192-bit key, or a 256-bit key.
              • DES—Data Encryption Standard. An algorithm that is used to encrypt packet data. Cisco software implements the mandatory 56-bit DES-CBC with Explicit IV. Cipher Block Chaining (CBC) requires an initialization vector (IV) to start encryption. The IV is explicitly given in the IPsec packet. For backwards compatibility, Cisco IOS IPsec also implements the RFC 1829 version of ESP DES-CBC.

              Cisco IOS also implements Triple DES (168-bit) encryption, depending on the software versions available for a specific platform. Cisco no longer recommends Triple DES (3DES).

              Cisco IOS images with strong encryption (including, but not limited to 56-bit data encryption feature sets) are subject to United States government export controls, and have a limited distribution. Images to be installed outside the United States require an export license. Customer orders might be denied or subject to delay due to United States government regulations. Contact your sales representative or distributor for more information, or send an e-mail to export@cisco.com.

              • SHA-2 and SHA-1 family (HMAC variant)—Secure Hash Algorithm (SHA) 1 and 2. Both SHA-1 and SHA-2 are hash algorithms used to authenticate packet data and verify the integrity verification mechanisms for the IKE protocol. HMAC is a variant that provides an additional level of hashing. SHA-2 family adds the SHA-256 bit hash algorithm and SHA-384 bit hash algorithm. This functionality is part of the Suite-B requirements that comprises four user interface suites of cryptographic algorithms for use with IKE and IPSec that are described in RFC 4869. Each suite consists of an encryption algorithm, a digital signature algorithm, a key agreement algorithm, and a hash or message digest algorithm. See the Configuring Security for VPNs with IPsec feature module for more detailed information about Cisco IOS Suite-B support.
              • Diffie-Hellman—A public-key cryptography protocol that allows two parties to establish a shared secret over an unsecure communications channel. Diffie-Hellman is used within IKE to establish session keys. It supports 768-bit (the default), 1024-bit, 1536-bit, 2048-bit, 3072-bit, and 4096-bit DH groups. It also supports a 2048-bit DH group with a 256-bit subgroup, and 256-bit and 384-bit elliptic curve DH (ECDH). Cisco recommends using 2048-bit or larger DH key exchange, or ECDH key exchange.
              • MD5 (Hash-based Message Authentication Code (HMAC) variant)—Message digest algorithm 5 (MD5) is a hash algorithm. HMAC is a keyed hash variant used to authenticate data.

              IPsec as implemented in Cisco software supports the following additional standards:

              • AH—Authentication Header. A security protocol, which provides data authentication and optional anti-replay services. AH is embedded in the data to be protected (a full IP datagram).
              • ESP—Encapsulating Security Payload. A security protocol, which provides data privacy services and optional data authentication, and anti-replay services. ESP encapsulates the data to be protected.

              Supported Encapsulation

              IPsec works with the following serial encapsulations: Frame Relay, High-Level Data-Links Control (HDLC), and PPP.

              IPsec also works with Generic Routing Encapsulation (GRE) and IPinIP Layer 3, Data Link Switching+ (DLSw+), and Source Route Bridging (SRB) tunneling protocols; however, multipoint tunnels are not supported. Other Layer 3 tunneling protocols may not be supported for use with IPsec.

              IPsec Functionality Overview

              IPsec provides the following network security services. (In general, the local security policy dictates the use of one or more of these services.)

              • Data confidentiality—The IPsec sender can encrypt packets before transmitting them across a network.
              • Data integrity—The IPsec receiver can authenticate packets sent by the IPsec sender to ensure that the data has not been altered during transmission.
              • Data origin authentication—The IPsec receiver can authenticate the source of the sent IPsec packets. This service is dependent upon the data integrity service.
              • Anti-replay—The IPsec receiver can detect and reject replayed packets.

              IPsec provides secure tunnels between two peers, such as two routers. You define which packets are considered sensitive and should be sent through these secure tunnels, and you define the parameters that should be used to protect these sensitive packets by specifying the characteristics of these tunnels. When the IPsec peer recognizes a sensitive packet, the peer sets up the appropriate secure tunnel and sends the packet through the tunnel to the remote peer. (The use of the term tunnel in this chapter does not refer to using IPsec in tunnel mode.)

              More accurately, these tunnels are sets of security associations (SAs) that are established between two IPsec peers. The SAs define the protocols and algorithms to be applied to sensitive packets and specify the keying material to be used by the two peers. SAs are unidirectional and are established per security protocol (AH or ESP).

              Multiple IPsec tunnels can exist between two peers to secure different data streams, with each tunnel using a separate set of SAs. For example, some data streams only need to be authenticated, while other data streams must both be encrypted and authenticated.

              IKEv1 Transform Sets

              An Internet Key Exchange version 1 (IKEv1) transform set represents a certain combination of security protocols and algorithms. During the IPsec SA negotiation, the peers agree to use a particular transform set for protecting a particular data flow.

              IKEv2 Transform Sets

              An Internet Key Exchange version 2 (IKEv2) proposal is a set of transforms used in the negotiation of IKEv2 SA as part of the IKE_SA_INIT exchange. An IKEv2 proposal is regarded as complete only when it has at least an encryption algorithm, an integrity algorithm, and a Diffie-Hellman (DH) group configured. If no proposal is configured and attached to an IKEv2 policy, then the default proposal is used in the negotiation. The default proposal is a collection of commonly used algorithms which are as follows:

               encryption aes-cbc-128 3des integrity sha1 md5 group 5 2 

              Although the crypto ikev2 proposal command is similar to the crypto isakmp policy priority command, the IKEv2 proposal differs as follows:

              • An IKEv2 proposal allows configuration of one or more transforms for each transform type.
              • An IKEv2 proposal does not have any associated priority.

              To use IKEv2 proposals in negotiation, they must be attached to IKEv2 policies. If a proposal is not configured, then the default IKEv2 proposal is used with the default IKEv2 policy.

              Transform Sets: A Combination of Security Protocols and Algorithms

              About Transform Sets

              Cisco no longer recommends using ah-md5-hmac, esp-md5-hmac, esp-des or esp-3des. Instead, you should use ah-sha-hmac, esp-sha-hmac or esp-aes. For more information about the latest Cisco cryptographic recommendations, see the Next Generation Encryption (NGE) white paper.

              A transform set represents a certain combination of security protocols and algorithms. During the IPsec SA negotiation, the peers agree to use a particular transform set for protecting a particular data flow.

              During IPsec security association negotiations with IKE, peers search for an identical transform set for both peers. When such a transform set is found, it is selected and applied to the protected traffic as part of both peers’ IPsec SAs. (With manually established SAs, there is no negotiation with the peer, so both sides must specify the same transform set.)

              The table below shows allowed transform combinations.

              AH Transform (Pick only one.)

              AH with the MD5 (Message Digest 5) (an HMAC variant) authentication algorithm. (No longer recommended).

              AH with the SHA (Secure Hash Algorithm) (an HMAC variant) authentication algorithm.

              ESP Encryption Transform (Pick only one.)

              ESP with the 128-bit Advanced Encryption Standard (AES) encryption algorithm.

              ESP with the 192-bit AES encryption algorithm.

              ESP with the 256-bit AES encryption algorithm.

              ESP with the 56-bit Data Encryption Standard (DES) encryption algorithm. (No longer recommended).

              ESP with the 168-bit DES encryption algorithm (3DES or Triple DES). (No longer recommended).

              ESP Authentication Transform (Pick only one.)

              ESP with the MD5 (HMAC variant) authentication algorithm. (No longer recommended).

              ESP with the SHA (HMAC variant) authentication algorithm.

              Security threats, as well as the cryptographic technologies to help protect against them, are constantly changing. For more information about the latest Cisco cryptographic recommendations, see the Next Generation Encryption (NGE) white paper.

              Cisco IOS Suite-B Support for IKE and IPsec Cryptographic Algorithms

              Suite-B has the following cryptographic algorithms:

              • Suite-B-GCM-128-Provides ESP integrity protection, confidentiality, and IPsec encryption algorithms that use the 128-bit AES using Galois and Counter Mode (AES-GCM) described in RFC 4106. This suite should be used when ESP integrity protection and encryption are both needed.
              • Suite-B-GCM-256-Provides ESP integrity protection and confidentiality using 256-bit AES-GCM described in RFC 4106. This suite should be used when ESP integrity protection and encryption are both needed.
              • Suite-B-GMAC-128-Provides ESP integrity protection using 128-bit AES- Galois Message Authentication Code (GMAC) described in RFC 4543, but does not provide confidentiality. This suite should be used only when there is no need for ESP encryption.
              • Suite-B-GMAC-256-Provides ESP integrity protection using 256-bit AES-GMAC described in RFC 4543, but does not provide confidentiality. This suite should be used only when there is no need for ESP encryption.

              IPSec encryption algorithms use AES-GCM when encryption is required and AES-GMAC for message integrity without encryption.

              IKE negotiation uses AES Cipher Block Chaining (CBC) mode to provide encryption and Secure Hash Algorithm (SHA)-2 family containing the SHA-256 and SHA-384 hash algorithms, as defined in RFC 4634, to provide the hash functionality. Diffie-Hellman using Elliptic Curves (ECP), as defined in RFC 4753, is used for key exchange and the Elliptic Curve Digital Signature Algorithm (ECDSA), as defined in RFC 4754, to provide authentication.

              Suite-B Requirements

              Suite-B imposes the following software crypto engine requirements for IKE and IPsec:

              • HMAC-SHA256 and HMAC-SHA384 are used as pseudorandom functions; the integrity check within the IKE protocol is used. Optionally, HMAC-SHA512 can be used.
              • Elliptic curve groups 19 (256-bit ECP curve) and 20 (384-bit ECP curve) are used as the Diffie-Hellman group in IKE. Optionally, group 21 (521-bit ECP curve) can be used.
              • The Elliptic Curve Digital Signature Algorithm (ECDSA) algorithm (256-bit and 384-bit curves) is used for the signature operation within X.509 certificates.
              • GCM (16 byte ICV) and GMAC is used for ESP (128-bit and 256-bit keys). Optionally, 192-bit keys can be used.
              • Public Key Infrastructure (PKI) support for validation of X.509 certificates using ECDSA signatures must be used.
              • PKI support for generating certificate requests using ECDSA signatures and for importing the issued certificates into IOS must be used.
              • IKEV2 support for allowing the ECDSA signature (ECDSA-sig) as authentication method must be used.

              Where to Find Suite-B Configuration Information

              Suite-B configuration support is described in the following documents:

              • For more information on SHA-2 family (HMAC variant) and Elliptic Curve (EC) key pair configuration, see the Configuring Internet Key Exchange for IPsec VPNs feature module.
              • For more information on configuring a transform for an integrity algorithm type, see the “Configuring the IKEv2 Proposal” section in the Configuring Internet Key Exchange Version 2 (IKEv2) and FlexVPN Site-to-Site feature module.
              • For more information on configuring the ECDSA-sig to be the authentication method for IKEv2, see the “Configuring IKEv2 Profile (Basic)” section in the Configuring Internet Key Exchange Version 2 (IKEv2) and FlexVPN Site-to-Site feature module.
              • For more information on configuring elliptic curve Diffie-Hellman (ECDH) support for IPsec SA negotiation, see the Configuring Internet Key Exchange for IPsec VPNs and Configuring Internet Key Exchange Version 2 and FlexVPN feature modules.

              For more information on the Suite-B support for certificate enrollment for a PKI, see the Configuring Certificate Enrollment for a PKI feature module.

              How to Configure IPsec VPNs

              Creating Crypto Access Lists

              SUMMARY STEPS

              1. enable
              2. configure terminal
              3. Do one of the following:
                 • access-list access-list-number < deny | permit >protocol source source-wildcard destination destination-wildcard [ log ]
                 • ip access-list extended name
              4. Repeat Step 3 for each crypto access list you want to create.

              DETAILED STEPS

              Example:

              Device> enable

              Enables privileged EXEC mode.

              • Enter your password if prompted.

              Example:

              Device# configure terminal

              Enters global configuration mode.

              Do one of the following:

              • access-list access-list-number < deny | permit >protocol source source-wildcard destination destination-wildcard [ log ]
              • ip access-list extended name

              Example:

              Device(config)# access-list 100 permit ip 10.0.68.0 0.0.0.255 10.1.1.0 0.0.0.255

              Example:

              Device(config)# ip access-list extended vpn-tunnel

              Specifies conditions to determine which IP packets are protected.

              • You specify conditions using an IP access list designated by either a number or a name. The access-list command designates a numbered extended access list; the ip access-list extended command designates a named access list.
              • Enable or disable crypto for traffic that matches these conditions.

              Cisco recommends that you configure “mirror image” crypto access lists for use by IPsec and that you avoid using the any keyword.

              Repeat Step 3 for each crypto access list you want to create.

              What to Do Next

              After at least one crypto access list is created, a transform set needs to be defined as described in the “Configuring Transform Sets for IKEv1 and IKEv2 Proposals” section.

              Next the crypto access lists need to be associated to particular interfaces when you configure and apply crypto map sets to the interfaces. (Follow the instructions in the “Creating Crypto Map Sets” and “Applying Crypto Map Sets to Interfaces” sections).

              Configuring Transform Sets for IKEv1 and IKEv2 Proposals

              Perform this task to define a transform set that is to be used by the IPsec peers during IPsec security association negotiations with IKEv1 and IKEv2 proposals.

              • From Cisco IOS XE Release 17.6 through 17.9, both tunnel and transport modes are supported for crypto map based VPN solutions.
              • From Cisco IOS XE Release 17.10, only transport mode is supported for crypto map based VPN solutions.

              Restrictions

              If you are specifying SEAL encryption, note the following restrictions:

              • Your router and the other peer must not have a hardware IPsec encryption.
              • Your router and the other peer must support IPsec.
              • Your router and the other peer must support the k9 subsystem.
              • SEAL encryption is available only on Cisco equipment. Therefore, interoperability is not possible.
              • Unlike IKEv1, the authentication method and SA lifetime are not negotiable in IKEv2, and because of this, these parameters cannot be configured under the IKEv2 proposal.

              Configuring Transform Sets for IKEv1

              SUMMARY STEPS

              1. enable
              2. configure terminal
              3. crypto ipsec transform-set transform-set-name transform1 [ transform2 [ transform3 ]]
              4. mode [ tunnel | transport ]
              5. end
              6. clear crypto sa [ peer < ip-address | peer-name >| sa map map-name | sa entry destination-address protocol spi ]
              7. show crypto ipsec transform-set [ tag transform-set-name ]

              DETAILED STEPS

              Example:

              Device> enable

              Enables privileged EXEC mode.

              • Enter your password if prompted.

              Example:

              Device# configure terminal

              Enters global configuration mode.

              crypto ipsec transform-set transform-set-name transform1 [ transform2 [ transform3 ]]

              Example:

              Device(config)# crypto ipsec transform-set aesset esp-aes 256 esp-sha-hmac

              Defines a transform set and enters crypto transform configuration mode.

              • There are complex rules defining the entries that you can use for transform arguments. These rules are explained in the command description for the crypto ipsec transform-set command, and the table in “About Transform Sets” section provides a list of allowed transform combinations.

              mode [ tunnel | transport ]

              Example:

              Device(cfg-crypto-tran)# mode transport

              (Optional) Changes the mode associated with the transform set.

              • The mode setting is applicable only to traffic whose source and destination addresses are the IPsec peer addresses; it is ignored for all other traffic. (All other traffic is in tunnel mode only.)

              Example:

              Device(cfg-crypto-tran)# end

              Exits crypto transform configuration mode and enters privileged EXEC mode.

              clear crypto sa [ peer < ip-address | peer-name >| sa map map-name | sa entry destination-address protocol spi ]

              Example:

              Device# clear crypto sa 

              (Optional) Clears existing IPsec security associations so that any changes to a transform set takes effect on subsequently established security associations.

              Manually established SAs are reestablished immediately.

              • Using the clear crypto sa command without parameters clears out the full SA database, which clears out active security sessions.
              • You may also specify the peer , map , or entry keywords to clear out only a subset of the SA database.

              show crypto ipsec transform-set [ tag transform-set-name ]

              Example:

              Device# show crypto ipsec transform-set

              (Optional) Displays the configured transform sets.

              What to Do Next

              After you have defined a transform set, you should create a crypto map as specified in theCreating Crypto Map Sets section.

              Configuring Transform Sets for IKEv2

              SUMMARY STEPS

              1. enable
              2. configure terminal
              3. crypto ikev2 proposal proposal-name
              4. encryption transform1 [ transform2 ] .
              5. integrity transform1 [ transform2 ] .
              6. group transform1 [ transform2 ] .
              7. end
              8. show crypto ikev2 proposal

              DETAILED STEPS

              Example:

              Device> enable

              Enables privileged EXEC mode.

              • Enter your password if prompted.

              Example:

              Device# configure terminal

              Enters global configuration mode.

              crypto ikev2 proposal proposal-name

              Example:

              Device(config)# crypto ikev2 proposal proposal-1

              Specifies the name of the proposal and enters crypto IKEv2 proposal configuration mode.

              • The proposals are referred in IKEv2 policies through the proposal name.

              encryption transform1 [ transform2 ] .

              Example:

              Device(config-ikev2-proposal)# encryption aes-cbc-128

              (Optional) Specifies one or more transforms of the following encryption type:

              • AES-CBC 128—128-bit AES-CBC
              • AES-CBC 192—192-bit AES-CBC
              • AES-CBC 256—256-bit AES-CBC
              • 3DES—168-bit DES (No longer recommended. AES is the recommended encryption algorithm).

              integrity transform1 [ transform2 ] .

              Example:

              Device(config-ikev2-proposal)# integrity sha1

              (Optional) Specifies one or more transforms of the following integrity type:

              • The sha256 keyword specifies SHA-2 family 256-bit (HMAC variant) as the hash algorithm.
              • The sha384 keyword specifies SHA-2 family 384-bit (HMAC variant) as the hash algorithm.
              • The sha512 keyword specifies SHA-2 family 512-bit (HMAC variant) as the hash algorithm
              • the sha1 keyword specifies the SHA-1 (HMAC variant) as the hash algorithm.
              • The md5 keyword specifies MD5 (HMAC variant) as the hash algorithm. (No longer recommended. SHA-1 is the recommended replacement.)

              group transform1 [ transform2 ] .

              Example:

              Device(config-ikev2-proposal)# group 14

              (Optional) Specifies one or more transforms of the possible DH group type:

              • 1 —768-bit DH (No longer recommended.)
              • 2 —1024-bit DH (No longer recommended)
              • 5 —1536-bit DH (No longer recommended)
              • 14 —Specifies the 2048-bit DH group.
              • 15 —Specifies the 3072-bit DH group.
              • 16 —Specifies the 4096-bit DH group.
              • 19 —Specifies the 256-bit elliptic curve DH (ECDH) group.
              • 20 —Specifies the 384-bit ECDH group.
              • 24 —Specifies the 2048-bit DH/DSA group.

              Example:

              Device(config-ikev2-proposal)# end

              Exits crypto IKEv2 proposal configuration mode and returns to privileged EXEC mode.

              show crypto ikev2 proposal

              Example:

              Device# show crypto ikev2 proposal

              (Optional) Displays the parameters for each IKEv2 proposal.

              Transform Sets for IKEv2 Examples

              The following examples show how to configure a proposal:

              IKEv2 Proposal with One Transform for Each Transform Type

               Device(config)# crypto ikev2 proposal proposal-1 Device(config-ikev2-proposal)# encryption aes-cbc-128 Device(config-ikev2-proposal)# integrity sha1 Device(config-ikev2-proposal)# group 14 

              IKEv2 Proposal with Multiple Transforms for Each Transform Type

               crypto ikev2 proposal proposal-2 encryption aes-cbc-128 aes-cbc-192 integrity sha1 sha256 group 14 15

              For a list of transform combinations, see Configuring Security for VPNs with IPsec.

              IKEv2 Proposals on the Initiator and Responder

              The proposal of the initiator is as follows:

               Device(config)# crypto ikev2 proposal proposal-1 Device(config-ikev2-proposal)# encryption aes-cbc-128 aes-cbc-196 Device(config-ikev2-proposal)# integrity sha1 sha256 Device(config-ikev2-proposal)# group 14 16 

              The proposal of the responder is as follows:

               Device(config)# crypto ikev2 proposal proposal-2 Device(config-ikev2-proposal)# encryption aes-cbc-196 aes-cbc-128 Device(config-ikev2-proposal)# integrity sha256 sha1 Device(config-ikev2-proposal)# group 16 14 

              In the scenario, the initiator’s choice of algorithms is preferred and the selected algorithms are as follows:

               encryption aes-cbc-128 integrity sha1 group 14

              What to Do Next

              After you have defined a transform set, you should create a crypto map as specified in the Creating Crypto Map Sets section.

              Enabling Security Association Strength Enforcement

              This section describes the strength enforcement of the IKE SA encryption ciphers over child IPsec SA encryption cipher. This feature is implemented as a part of the Common Criteria (CC) certification requirement. It ensures that the strength of the IKE (IKEv1 and IKEv2) SA encryption cipher is greater than or equal to the strength of its child IPsec SA encryption cipher.

              Information About Security Association Strength Enforcement

              The following section provides detailed information relating to the Security Association Strength Enforcement feature.

              Overview

              It is a good security practice to configure IPSec such that the strength of the IKE SA encryption cipher is greater than or equal to the strength of its child IPsec SA encryption cipher. The strength enforcement only checks the encryption cipher. It does not check the integrity or key exchange algorithms. The encryption cipher strength comparison is done during session negotiation or establishment. It is not enforced during the configuration of IKE or IPsec. The number of bits in the encryption key determines the strength of the encryption cipher.

              This feature is disabled by default. When enabled, the IKEv1 and IKEv2 sessions compare the relative strength of each child SA’s selected encryption cipher. If the child SA’s encryption algorithm is stronger than the IKEv1 or IKEv2 encryption algorithms, the child SA negotiation will be aborted, and a new high-severity syslog and debug message are issued to identify the cause of the failed negotiation.

              The following table lists the supported encryption ciphers in order of strength (from highest to lowest). The encryption ciphers on the same line have equivalent strength for purposes of this check.

              AES-CBC-256 (default), AES-GCM-256

              ESP-AES-128 (default), ESP-GCM-128

              This feature is applicable only to the Encapsulating Security Payload (ESP) protocol. There is no impact on the Authentication Header (AH) protocol.

              Supported Platforms for Security Association Strength Enforcement

              The following are the supported platforms for Security Association Strength Enforcement:

              • Cisco ASR 1000 Series Aggregation Services Routers
              • Cisco 1000 Series Integrated Services Routers
              • Cisco Catalyst 8200 Series Edge Platforms
              • Cisco Catalyst 8300 Series Edge Platforms
              • Cisco Catalyst 8500 Series Edge Platforms
              • Cisco Catalyst 8000V Edge Software

              How to configure Security Association Strength Enforcement

              The following section describes the process involved in configuring Security Association Strength Enforcement.

              Configuring Security Association Strength Enforcement

              Follow these steps to configure SA strength enforcement.

              • This is a global configuration applicable to IKEv1 and IKEv2. You cannot enable or disable the Security Association Strength Enforcement feature separately for IKEv1 or IKEv2.
              • If the existing IPSec sessions are not cleared, the SA strength enforcement is applied at the time of IPSec rekey.

              SUMMARY STEPS

              1. enable
              2. configure terminal
              3. crypto ipsec ike sa-strength-enforcement
              4. exit

              DETAILED STEPS

              Example:

              Device> enable

              Enables privileged EXEC mode.

              Enter your password if prompted.

              Example:

              Device# configure terminal

              Enters global configuration mode.

              crypto ipsec ike sa-strength-enforcement

              Example:

              Device(config)# crypto ipsec ike sa-strength-enforcement

              Ensures that the strength of the IKE SA encryption cipher is greater than or equal to the strength of its child IPsec SA encryption cipher.

              Example:

              Device(config)# exit

              Exits global configuration mode and enters privileged EXEC mode.

              Configuration Examples for Security Association Strength Enforcement

              The following section provides detailed configuration example relating to the configuration of SA strength enforcement.

              Example: Configuring Security Association Strength Enforcement

              Router(config)#crypto ipsec ike sa-strength-enforcement % Warning: Please make sure IKE SA encryption keysize configured, is greater than or equal to IPSec SA encryption keysize. Please run "clear crypto session" to enforce stronger IKE SA encryption immediately.

              Verifying Security Association Strength Enforcement

              Use the show crypto session detail command to display the status of the crypto session. The E displayed next to IKE Capabilities in the output indicates that the stronger IKE encryption is enforced.

              The following is a sample output from the show crypto session detail command.

              Router#show crypto session detail Crypto session current status Code: C - IKE Configuration mode, D - Dead Peer Detection K - Keepalives, N - NAT-traversal, T - cTCP encapsulation X - IKE Extended Authentication, F - IKE Fragmentation R - IKE Auto Reconnect, U - IKE Dynamic Route Update S - SIP VPN, E – Stronger IKE Encryption Enforced Interface: Tunnel0 Uptime: 00:09:29 Session status: UP-ACTIVE Peer: 10.0.149.217 port 500 fvrf: (none) ivrf: (none) Phase1_id: 10.0.149.217 Desc: (none) Session ID: 0 IKEv1 SA: local 10.0.149.203/500 remote 10.0.149.217/500 Active Capabilities: DE connid:1001 lifetime:00:20:30 IPSEC FLOW: permit ip 0.0.0.0/0.0.0.0 0.0.0.0/0.0.0.0 Active SAs: 2, origin: crypto map Inbound: #pkts dec'ed 0 drop 0 life (KB/Sec) 4154754/330 Outbound: #pkts enc'ed 0 drop 0 life (KB/Sec) 4154754/330

              Creating Crypto Map Sets

              Perform the following tasks to create static and dynamic crypto maps.

              • From Cisco IOS XE Release 17.6 through 17.9, the crypto map set supports both the tunnel and the transport modes.
              • From Cisco IOS XE Release 17.10, the crypto map set supports the transport mode only.

              Creating Static Crypto Maps

              When IKE is used to establish SAs, the IPsec peers can negotiate the settings they use for the new security associations. This means that you can specify lists (such as lists of acceptable transforms) within the crypto map entry.

              Perform this task to create crypto map entries that use IKE to establish SAs. To create IPv6 crypto map entries, you must use the ipv6 keyword with the crypto map command. For IPv4 crypto maps, use the crypto map command without the ipv6 keyword.

              Security threats, as well as the cryptographic technologies to help protect against them, are constantly changing. For more information about the latest Cisco cryptographic recommendations, see the Next Generation Encryption (NGE) white paper.

              SUMMARY STEPS

              1. enable
              2. configure terminal
              3. crypto map [ ipv6 ] map-name seq-num [ ipsec-isakmp ]
              4. match address access-list-id
              5. set peer
              6. crypto ipsec security-association dummy
              7. set transform-set transform-set-name1 [ transform-set-name2. transform-set-name6 ]
              8. set security-association lifetime
              9. set security-association level per-host
              10. set pfs [ group1 | group14 | group15 | group16 | group19 | group2 | group20 | group24 | group5 ]
              11. end
              12. show crypto map [ interface interface | tag map-name ]

              DETAILED STEPS

              Example:

              Device> enable

              Enables privileged EXEC mode.

              • Enter your password if prompted.

              Example:

              Device# configure terminal

              Enters global configuration mode.

              crypto map [ ipv6 ] map-name seq-num [ ipsec-isakmp ]

              Example:

              Device(config)# crypto map static-map 1 ipsec-isakmp

              Creates or modifies a crypto map entry, and enters crypto map configuration mode.

              • For IPv4 crypto maps, use the command without the ipv6 keyword.

              match address access-list-id

              Example:

              Device(config-crypto-m)# match address vpn-tunnel

              Names an extended access list.

              • This access list determines the traffic that should be protected by IPsec and the traffic that should not be protected by IPsec security in the context of this crypto map entry.

              Example:

              Device(config-crypto-m)# set-peer 192.168.101.1

              Specifies a remote IPsec peer—the peer to which IPsec protected traffic can be forwarded.

              • Repeat for multiple remote peers.

              crypto ipsec security-association dummy

              Example:

              Device(config-crypto-m)# set security-association dummy seconds 5

              Enables generating dummy packets. These dummy packets are generated for all flows created in the crypto map.

              set transform-set transform-set-name1 [ transform-set-name2. transform-set-name6 ]

              Example:

              Device(config-crypto-m)# set transform-set aesset

              Specifies the transform sets that are allowed for this crypto map entry.

              • List multiple transform sets in the order of priority (highest priority first).

              set security-association lifetime

              Example:

              Device (config-crypto-m)# set security-association lifetime seconds 2700 

              (Optional) Specifies a SA lifetime for the crypto map entry.

              • By default, the SAs of the crypto map are negotiated according to the global lifetimes, which can be disabled.

              set security-association level per-host

              Example:

              Device(config-crypto-m)# set security-association level per-host

              (Optional) Specifies that separate SAs should be established for each source and destination host pair.

              • By default, a single IPsec “tunnel” can carry traffic for multiple source hosts and multiple destination hosts.

              Use this command with care because multiple streams between given subnets can rapidly consume resources.

              set pfs [ group1 | group14 | group15 | group16 | group19 | group2 | group20 | group24 | group5 ]

              Example:

              Device(config-crypto-m)# set pfs group14

              (Optional) Specifies that IPsec either should ask for password forward secrecy (PFS) when requesting new SAs for this crypto map entry or should demand PFS in requests received from the IPsec peer.

              • Group 1 specifies the 768-bit Diffie-Hellman (DH) identifier (default). (No longer recommended).
              • Group 2 specifies the 1024-bit DH identifier. (No longer recommended).
              • Group 5 specifies the 1536-bit DH identifier. (No longer recommended)
              • Group 14 specifies the 2048-bit DH identifier.
              • Group 15 specifies the 3072-bit DH identifier.
              • Group 16 specifies the 4096-bit DH identifier.
              • Group 19 specifies the 256-bit elliptic curve DH (ECDH) identifier.
              • Group 20 specifies the 384-bit ECDH identifier.
              • Group 24 specifies the 2048-bit DH/DSA identifier
              • By default, PFS is not requested. If no group is specified with this command, group 1 is used as the default.

              Example:

              Device(config-crypto-m)# end

              Exits crypto map configuration mode and returns to privileged EXEC mode.

              show crypto map [ interface interface | tag map-name ]

              Example:

              Device# show crypto map

              Displays your crypto map configuration.

              Troubleshooting Tips

              Certain configuration changes take effect only when negotiating subsequent SAs. If you want the new settings to take immediate effect, you must clear the existing SAs so that they are reestablished with the changed configuration. If the router is actively processing IPsec traffic, clear only the portion of the SA database that would be affected by the configuration changes (that is, clear only the SAs established by a given crypto map set). Clearing the full SA database should be reserved for large-scale changes, or when the router is processing very little other IPsec traffic.

              To clear IPsec SAs, use the clear crypto sa command with appropriate parameters. (Omitting all parameters clears out the full SA database, which clears active security sessions.)

              What to Do Next

              After you have successfully created a static crypto map, you must apply the crypto map set to each interface through which IPsec traffic flows. To complete this task, see the Applying Crypto Map Sets to Interfaces section.

              Creating Dynamic Crypto Maps

              Dynamic crypto map entries specify crypto access lists that limit traffic for which IPsec SAs can be established. A dynamic crypto map entry that does not specify an access list is ignored during traffic filtering. A dynamic crypto map entry with an empty access list causes traffic to be dropped. If there is only one dynamic crypto map entry in the crypto map set, it must specify the acceptable transform sets.

              Perform this task to create dynamic crypto map entries that use IKE to establish the SAs.

              IPv6 addresses are not supported on dynamic crypto maps.

              Security threats, as well as the cryptographic technologies to help protect against them, are constantly changing. For more information about the latest Cisco cryptographic recommendations, see the Next Generation Encryption (NGE) white paper.

              SUMMARY STEPS

              1. enable
              2. configure terminal
              3. crypto dynamic-map dynamic-map-name dynamic-seq-num
              4. set transform-set transform-set-name1 [ transform-set-name2. transform-set-name6 ]
              5. match address access-list-id
              6. set peer
              7. set security-association lifetime
              8. set pfs [ group1 | group14 | group15 | group16 | group19 | group2 | group20 | group24 | group5 ]
              9. exit
              10. exit
              11. show crypto dynamic-map [ tag map-name ]
              12. configure terminal
              13. crypto map map-name seq-num ipsec-isakmp dynamic dynamic-map-name [ discover ]
              14. exit

              DETAILED STEPS

              Example:

              Device> enable

              Enables privileged EXEC mode.

              • Enter your password if prompted.

              Example:

              Device# configure terminal

              Enters global configuration mode.

              crypto dynamic-map dynamic-map-name dynamic-seq-num

              Example:

              Device(config)# crypto dynamic-map test-map 1

              Creates a dynamic crypto map entry and enters crypto map configuration mode.

              set transform-set transform-set-name1 [ transform-set-name2. transform-set-name6 ]

              Example:

              Device(config-crypto-m)# set transform-set aesset

              Specifies the transform sets allowed for the crypto map entry.

              • List multiple transform sets in the order of priority (highest priority first). This is the only configuration statement required in dynamic crypto map entries.

              match address access-list-id

              Example:

              Device(config-crypto-m)# match address 101

              (Optional) Specifies the list number or name of an extended access list.

              • This access list determines which traffic should be protected by IPsec and which traffic should not be protected by IPsec security in the context of this crypto map entry.

              Although access lists are optional for dynamic crypto maps, they are highly recommended.

              • If an access list is configured, the data flow identity proposed by the IPsec peer must fall within a permit statement for this crypto access list.
              • If an access list is not configured, the device accepts any data flow identity proposed by the IPsec peer. However, if an access list is configured but the specified access list does not exist or is empty, the device drops all packets. This is similar to static crypto maps, which require access lists to be specified.
              • Care must be taken if the any keyword is used in the access list, because the access list is used for packet filtering as well as for negotiation.
              • You must configure a match address; otherwise, the behavior is not secure, and you cannot enable TED because packets are sent in the clear (unencrypted.)

              Example:

              Device(config-crypto-m)# set peer 192.168.101.1

              (Optional) Specifies a remote IPsec peer. Repeat this step for multiple remote peers.

              This is rarely configured in dynamic crypto map entries. Dynamic crypto map entries are often used for unknown remote peers.

              set security-association lifetime

              Example:

              Device(config-crypto-m)# set security-association lifetime seconds 7200

              (Optional) Overrides (for a particular crypto map entry) the global lifetime value, which is used when negotiating IP Security SAs.

              To minimize the possibility of packet loss when rekeying in high bandwidth environments, you can disable the rekey request triggered by a volume lifetime expiry.

              set pfs [ group1 | group14 | group15 | group16 | group19 | group2 | group20 | group24 | group5 ]

              Example:

              Device(config-crypto-m)# set pfs group14

              (Optional) Specifies that IPsec should ask for PFS when requesting new security associations for this crypto map entry or should demand PFS in requests received from the IPsec peer.

              • Group 1 specifies the 768-bit Diffie-Hellman (DH) identifier (default). (No longer recommended).
              • Group 2 specifies the 1024-bit DH identifier. (No longer recommended).
              • Group 5 specifies the 1536-bit DH identifier. (No longer recommended)
              • Group 14 specifies the 2048-bit DH identifier.
              • Group 15 specifies the 3072-bit DH identifier.
              • Group 16 specifies the 4096-bit DH identifier.
              • Group 19 specifies the 256-bit elliptic curve DH (ECDH) identifier.
              • Group 20 specifies the 384-bit ECDH identifier.
              • Group 24 specifies the 2048-bit DH/DSA identifier
              • By default, PFS is not requested. If no group is specified with this command, group1 is used as the default.

              Example:

              Device(config-crypto-m)# exit

              Exits crypto map configuration mode and returns to global configuration mode.

              Example:

              Device(config)# exit

              Exits global configuration mode.

              show crypto dynamic-map [ tag map-name ]

              Example:

              Device# show crypto dynamic-map

              (Optional) Displays information about dynamic crypto maps.

              Example:

              Device# configure terminal

              Enters global configuration mode.

              crypto map map-name seq-num ipsec-isakmp dynamic dynamic-map-name [ discover ]

              Example:

              Device(config)# crypto map static-map 1 ipsec-isakmp dynamic test-map discover

              (Optional) Adds a dynamic crypto map to a crypto map set.

              • You should set the crypto map entries referencing dynamic maps to the lowest priority entries in a crypto map set.

              You must enter the discover keyword to enable TED.

              Example:

              Device(config)# exit

              Exits global configuration mode.

              Troubleshooting Tips

              Certain configuration changes take effect only when negotiating subsequent SAs. If you want the new settings to take immediate effect, you must clear the existing SAs so that they are reestablished with the changed configuration. If the router is actively processing IPsec traffic, clear only the portion of the SA database that would be affected by the configuration changes (that is, clear only the SAs established by a given crypto map set). Clearing the entire SA database must be reserved for large-scale changes, or when the router is processing minimal IPsec traffic.

              To clear IPsec SAs, use the clear crypto sa command with appropriate parameters. (Omitting all parameters clears the full SA database, which clears active security sessions.)

              What to Do Next

              After you have successfully created a crypto map set, you must apply the crypto map set to each interface through which IPsec traffic flows. To complete this task, see the “Applying Crypto Map Sets to Interfaces” section.

              Creating Crypto Map Entries to Establish Manual SAs

              Perform this task to create crypto map entries to establish manual SAs (that is, when IKE is not used to establish the SAs). To create IPv6 crypto maps entries, you must use the ipv6 keyword with the crypto map command. For IPv4 crypto maps, use the crypto map command without the ipv6 keyword.

              SUMMARY STEPS

              1. enable
              2. configure terminal
              3. crypto map [ ipv6 ] map-name seq-num [ ipsec-manual ]
              4. match address access-list-id
              5. set peer
              6. set transform-set transform-set-name
              7. Do one of the following:
                 • set session-key inbound ah spi hex-key-string
                 • set session-key outbound ah spi hex-key-string
              8. Do one of the following:
                 • set session-key inbound esp spi cipher hex-key-string [ authenticator hex-key-string ]
                 • set session-key outbound esp spi cipher hex-key-string [ authenticator hex-key-string ]
              9. exit
              10. exit
              11. show crypto map [ interface interface | tag map-name ]

              DETAILED STEPS

              Example:

              Device> enable

              Enables privileged EXEC mode.

              • Enter your password if prompted.

              Example:

              Device# configure terminal

              Enters global configuration mode.

              crypto map [ ipv6 ] map-name seq-num [ ipsec-manual ]

              Example:

              Device(config)# crypto map mymap 10 ipsec-manual

              Specifies the crypto map entry to be created or modified and enters crypto map configuration mode.

              • For IPv4 crypto maps, use the crypto map command without the ipv6 keyword.

              match address access-list-id

              Example:

              Device(config-crypto-m)# match address 102

              Names an IPsec access list that determines which traffic should be protected by IPsec and which traffic should not be protected by IPsec in the context of this crypto map entry.

              • The access list can specify only one permit entry when IKE is not used.

              Example:

              Device(config-crypto-m)# set peer 10.0.0.5

              Specifies the remote IPsec peer. This is the peer to which IPsec protected traffic should be forwarded.

              • Only one peer can be specified when IKE is not used.

              set transform-set transform-set-name

              Example:

              Device(config-crypto-m)# set transform-set someset

              Specifies which transform set should be used.

              • This must be the same transform set that is specified in the remote peer’s corresponding crypto map entry.

              Only one transform set can be specified when IKE is not used.

              Do one of the following:

              • set session-key inbound ah spi hex-key-string
              • set session-key outbound ah spi hex-key-string

              Example:

              Device(config-crypto-m)# set session-key inbound ah 256 98765432109876549876543210987654

              Example:

              Device(config-crypto-m)# set session-key outbound ah 256 fedcbafedcbafedcfedcbafedcbafedc 

              Sets the AH security parameter indexes (SPIs) and keys to apply to inbound and outbound protected traffic if the specified transform set includes the AH protocol.

              • This manually specifies the AH security association to be used with protected traffic.

              Do one of the following:

              • set session-key inbound esp spi cipher hex-key-string [ authenticator hex-key-string ]
              • set session-key outbound esp spi cipher hex-key-string [ authenticator hex-key-string ]

              Example:

              Device(config-crypto-m)# set session-key inbound esp 256 cipher 0123456789012345 

              Example:

              Device(config-crypto-m)# set session-key outbound esp 256 cipher abcdefabcdefabcd

              Sets the Encapsulating Security Payload (ESP) Security Parameter Indexes (SPI) and keys to apply to inbound and outbound protected traffic if the specified transform set includes the ESP protocol.

              Specifies the cipher keys if the transform set includes an ESP cipher algorithm. Specifies the authenticator keys if the transform set includes an ESP authenticator algorithm.

              • This manually specifies the ESP security association to be used with protected traffic.

              Example:

              Device(config-crypto-m)# exit

              Exits crypto map configuration mode and returns to global configuration mode.

              Example:

              Device(config)# exit

              Exits global configuration mode.

              show crypto map [ interface interface | tag map-name ]

              Example:

              Device# show crypto map

              Displays your crypto map configuration.

              Troubleshooting Tips

              For manually established SAs, you must clear and reinitialize the SAs for the changes to take effect. To clear IPsec SAs, use the clear crypto sa command with appropriate parameters. (Omitting all parameters clears the entire SA database, which clears active security sessions.)

              What to Do Next

              After you have successfully created a crypto map set, you must apply the crypto map set to each interface through which IPsec traffic flows. To complete this task, see the “Applying Crypto Map Sets to Interfaces” section.

              Applying Crypto Map Sets to Interfaces

              You must apply a crypto map set to each interface through which IPsec traffic flows. Applying the crypto map set to an interface instructs the device to evaluate the interface’s traffic against the crypto map set and to use the specified policy during connection or security association negotiation on behalf of traffic to be protected by the crypto map.

              Perform this task to apply a crypto map to an interface.

              SUMMARY STEPS

              1. enable
              2. configure terminal
              3. interface type / number
              4. crypto map map-name
              5. exit
              6. crypto map map-name local-address interface-id
              7. exit
              8. show crypto map [ interface interface ]

              DETAILED STEPS

              Example:

              Device> enable

              Enables privileged EXEC mode.

              • Enter your password if prompted.

              Example:

              Device# configure terminal

              Enters global configuration mode.

              interface type / number

              Example:

              Device(config)# interface FastEthernet 0/0

              Configures an interface and enters interface configuration mode.

              crypto map map-name

              Example:

              Device(config-if)# crypto map mymap 

              Applies a crypto map set to an interface.

              Example:

              Device(config-if)# exit

              Exits interface configuration mode and returns to global configuration mode.

              crypto map map-name local-address interface-id

              Example:

              Device(config)# crypto map mymap local-address loopback0 

              (Optional) Permits redundant interfaces to share the same crypto map using the same local identity.

              Example:

              Device(config)# exit

              (Optional) Exits global configuration mode.

              show crypto map [ interface interface ]

              Example:

              Device# show crypto map

              (Optional) Displays your crypto map configuration

              Configuration Examples for IPsec VPN

              Example: Configuring AES-Based Static Crypto Map

              This example shows how a static crypto map is configured and how an AES is defined as the encryption method:

               crypto isakmp policy 10 encryption aes 256 authentication pre-share group 14 lifetime 180 crypto isakmp key cisco123 address 10.0.110.1 ! ! crypto ipsec transform-set aesset esp-aes 256 esp-sha-hmac mode transport ! crypto map aesmap 10 ipsec-isakmp set peer 10.0.110.1 set transform-set aesset match address 120 ! ! ! voice call carrier capacity active ! ! mta receive maximum-recipients 0 ! ! interface FastEthernet0/0 ip address 10.0.110.2 255.255.255.0 ip nat outside no ip route-cache no ip mroute-cache duplex auto speed auto crypto map aesmap ! interface Serial0/0 no ip address shutdown ! interface FastEthernet0/1 ip address 10.0.110.1 255.255.255.0 ip nat inside no ip route-cache no ip mroute-cache duplex auto speed auto ! ip nat inside source list 110 interface FastEthernet0/0 overload ip classless ip route 0.0.0.0 0.0.0.0 10.5.1.1 ip route 10.0.110.0 255.255.255.0 FastEthernet0/0 ip route 172.18.124.0 255.255.255.0 10.5.1.1 ip route 172.18.125.3 255.255.255.255 10.5.1.1 ip http server ! ! access-list 110 deny ip 10.0.110.0 0.0.0.255 10.0.110.0 0.0.0.255 access-list 110 permit ip 10.0.110.0 0.0.0.255 any access-list 120 permit ip 10.0.110.0 0.0.0.255 10.0.110.0 0.0.0.255 !

              Additional References for Configuring Security for VPNs with IPsec

              Related Documents

              Cisco IOS commands

              IKE, IPsec, and PKI configuration commands

              Configuring Internet Key Exchange for IPsec VPNs

              Suite-B SHA-2 family (HMAC variant) and Elliptic Curve (EC) key pair configuration

              Configuring Internet Key Exchange for IPsec VPNs

              Suite-B Integrity algorithm type transform configuration

              Configuring Internet Key Exchange Version 2 (IKEv2)

              Suite-B Elliptic Curve Digital Signature Algorithm (ECDSA) signature (ECDSA-sig) authentication method configuration for IKEv2

              Configuring Internet Key Exchange Version 2 (IKEv2)

              Suite-B Elliptic curve Diffie-Hellman (ECDH) support for IPsec SA negotiation

              Suite-B support for certificate enrollment for a PKI

              Configuring Certificate Enrollment for a PKI

              Recommended cryptographic algorithms

              Standards

              MIBs

              To locate and download MIBs for selected platforms, Cisco IOS software releases, and feature sets, use Cisco MIB Locator found at the following URL:

              RFCs

              Security Architecture for the Internet Protocol

              IP Authentication Header

              The Use of HMAC-MD5-96 within ESP and AH

              The Use of HMAC-SHA-1-96 within ESP and AH

              The ESP DES-CBC Cipher Algorithm With Explicit IV

              IP Encapsulating Security Payload (ESP)

              The Internet IP Security Domain of Interpretation for ISAKMP

              Internet Security Association and Key Management Protocol (ISAKMP)

              Technical Assistance

              The Cisco Support and Documentation website provides online resources to download documentation, software, and tools. Use these resources to install and configure the software and to troubleshoot and resolve technical issues with Cisco products and technologies. Access to most tools on the Cisco Support and Documentation website requires a Cisco.com user ID and password.

              Feature Information for Configuring Security for VPNs with IPsec

              The following table provides release information about the feature or features described in this module. This table lists only the software release that introduced support for a given feature in a given software release train. Unless noted otherwise, subsequent releases of that software release train also support that feature.

              Use Cisco Feature Navigator to find information about platform support and Cisco software image support. To access Cisco Feature Navigator, go to www.cisco.com/go/cfn. An account on Cisco.com is not required.

              Advanced Encryption Standard

              This feature adds support for the new encryption standard AES, which is a privacy transform for IPsec and IKE and has been developed to replace DES.

              The following commands were modified by this feature: crypto ipsec transform-set , encryption (IKE policy) , show crypto ipsec transform-set , show crypto isakmp policy .

              Suite-B Support in IOS SW Crypto

              Suite-B adds support for four user interface suites of cryptographic algorithms for use with IKE and IPSec that are described in RFC 4869. Each suite consists of an encryption algorithm, a digital signature algorithm, a key agreement algorithm, and a hash or message digest algorithm.

              The following command was modified by this feature: crypto ipsec transform-set .

              IKE Security Association (SA) Strength Enforcement

              Cisco IOS XE 17.13

              This feature ensures that the strength of the IKE (IKEv1 and IKEv2) SA encryption cipher is greater than or equal to the strength of its child IPsec SA encryption cipher.

              The crypto ipsec ike sa-strength-enforcement command was introduced to enable this feature.

              Glossary

              anti-replay —Security service where the receiver can reject old or duplicate packets to protect itself against replay attacks. IPsec provides this optional service by use of a sequence number combined with the use of data authentication. Cisco IOS XE IPsec provides this service whenever it provides the data authentication service, except for manually established SAs (that is, SAs established by configuration and not by IKE).

              data authentication —Verification of the integrity and origin of the data. Data authentication can refer either to integrity alone or to both of these concepts (although data origin authentication is dependent upon data integrity).

              data confidentiality —Security service in which the protected data cannot be observed.

              data flow —Grouping of traffic, identified by a combination of source address or mask, destination address or mask, IP next protocol field, and source and destination ports, where the protocol and port fields can have the values of any . IPsec protection is applied to data flows.

              IKE —Internet Key Exchange. IKE establishes a shared security policy and authenticates keys for services (such as IPSec) that require keys. Before any IPSec traffic can be passed, each router/firewall/host must verify the identity of its peer. This can be done by manually entering preshared keys into both hosts or by a CA service.

              IPsec —IP Security. A framework of open standards that provides data confidentiality, data integrity, and data authentication between participating peers. IPSec provides these security services at the IP layer. IPSec uses IKE to handle the negotiation of protocols and algorithms based on local policy and to generate the encryption and authentication keys to be used by IPSec. IPSec can protect one or more data flows between a pair of hosts, between a pair of security gateways, or between a security gateway and a host.

              peer —In the context of this module, a “peer” is a router or other device that participates in IPsec.

              PFS —perfect forward secrecy. Cryptographic characteristic associated with a derived shared secret value. With PFS, if one key is compromised, previous and subsequent keys are not compromised, because subsequent keys are not derived from previous keys.

              SA —security association. Description of how two or more entities use security services in the context of a particular security protocol (AH or ESP) to communicate securely on behalf of a particular data flow. The transform and the shared secret keys are used for protecting the traffic.

              SPI —security parameter index. A number which, together with a destination IP address and security protocol, uniquely identifies a particular security association. Without IKE, the SPI is manually specified for each security association.

              transform —List of operations performed on a dataflow to provide data authentication, data confidentiality, and data compression. For example, one transform is the ESP protocol with the HMAC-MD5 authentication algorithm; another transform is the AH protocol with the 56-bit DES encryption algorithm and the ESP protocol with the HMAC-SHA authentication algorithm.

              tunnel —In the context of this module, “tunnel” is a secure communication path between two peers, such as two routers. It does not refer to using IPsec in tunnel mode.