Security for VPNs with IPsec Configuration Guide, Cisco IOS XE Release 3S
Configuring Security for VPNs with IPsec
Downloads: This chapterpdf (PDF - 1.45 MB) The complete bookPDF (PDF - 2.83 MB) | The complete bookePub (ePub - 411.0 KB) | The complete bookMobi (Mobi - 783.0 KB) | Feedback

Configuring Security for VPNs with IPsec

Contents

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.


Note


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.


Finding Feature Information

Your software release may not support all the features documented in this module. For the latest caveats and feature information, see Bug Search Tool and the release notes for your platform and software release. To find information about the features documented in this module, and to see a list of the releases in which each feature is supported, see the feature information table.

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.

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.


Note


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

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.

Nested IPsec Tunnels

IPsec supports nested tunnels that terminate on the same router. Double encryption of locally generated IKE packets and IPsec packets is supported only when a static virtual tunnel interface (sVTI) is configured. Double encryption is supported on releases up to and including Cisco IOS Release 12.4(15)T, but not on later releases.

With CSCts46591, the following nested IPsec tunnels are supported:

  • Virtual tunnel interface (VTI) in VTI

  • VTI in Generic Routing Encapsulation (GRE)/IPsec

  • GRE/IPsec in VTI

  • GRE/IPsec in GRE/IPsec

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.

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.

Cisco IPsec Policy Map MIB

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

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.


  • IKE (IKEv1 and IKEv2)—A hybrid protocol that implements Oakley and SKEME key exchanges inside the Internet Security Association and Key Management Protocol (ISAKMP) framework. While IKE is used with other protocols, its initial implementation is with the IPsec protocol. IKE provides authentication of IPsec peers, negotiates IPsec security associations, and establishes IPsec keys.

The component technologies implemented for IPsec include:


Note


Cisco no longer recommends using DES, 3DES, MD5 (including HMAC variant), and Diffie-Hellman (DH) groups 1, 2 and 5; instead, you should use AES, SHA and DH Groups 14 or higher. For more information about the latest Cisco cryptographic recommendations, see the Next Generation Encryption (NGE) white paper.


  • 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).


Note


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. SHA-2 for ISAKMP is supported in Cisco IOS XE 15.3(3)S and later.

  • 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).

With IPsec, you can define the traffic that needs to be protected between two IPsec peers by configuring access lists and applying these access lists to interfaces using crypto map sets. Therefore, traffic may be selected on the basis of the source and destination address, and optionally the Layer 4 protocol and port. (The access lists used for IPsec are only used to determine the traffic that needs to be protected by IPsec, not the traffic that should be blocked or permitted through the interface. Separate access lists define blocking and permitting at the interface.)

A crypto map set can contain multiple entries, each with a different access list. The crypto map entries are searched in a sequence—the router attempts to match the packet to the access list specified in that entry.

When a packet matches a permit entry in a particular access list, and the corresponding crypto map entry is tagged as cisco, connections are established, if necessary. If the crypto map entry is tagged as ipsec-isakmp, IPsec is triggered. If there is no SA that the IPsec can use to protect this traffic to the peer, IPsec uses IKE to negotiate with the remote peer to set up the necessary IPsec SAs on behalf of the data flow. The negotiation uses information specified in the crypto map entry as well as the data flow information from the specific access list entry. (The behavior is different for dynamic crypto map entries. See the Creating Dynamic Crypto Maps section later in this module.)

If the crypto map entry is tagged as ipsec-manual, IPsec is triggered. If there is no SA that IPsec can use to protect this traffic to the peer, the traffic is dropped. In this case, the SAs are installed via the configuration, without the intervention of IKE. If SAs do not exist, IPsec does not have all the necessary pieces configured.

Once established, the set of SAs (outbound to the peer) is then applied to the triggering packet and to subsequent applicable packets as those packets exit the router. “Applicable” packets are packets that match the same access list criteria that the original packet matched. For example, all applicable packets could be encrypted before being forwarded to the remote peer. The corresponding inbound SAs are used when processing the incoming traffic from that peer.

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.

Access lists associated with IPsec crypto map entries also represent the traffic that the router needs protected by IPsec. Inbound traffic is processed against crypto map entries—if an unprotected packet matches a permit entry in a particular access list associated with an IPsec crypto map entry, that packet is dropped because it was not sent as an IPsec-protected packet.

Crypto map entries also include transform sets. A transform set is an acceptable combination of security protocols, algorithms, and other settings that can be applied to IPsec-protected traffic. During the IPsec SA negotiation, the peers agree to use a particular transform set when protecting a particular data flow.

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.

If you change a transform set definition, the change is applied only to crypto map entries that reference the transform set. The change is not applied to existing security associations, but is used in subsequent negotiations to establish new SAs.

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 sha md5
group 5 2

The transforms shown above translate to the following combinations in the following order of priority:

aes-cbc-128, sha, 5
aes-cbc-128, sha, 2
aes-cbc-128, md5, 5
aes-cbc-128, md5, 2
3des, sha1, 5
3des, sha1, 2
3des, md5, 5
3des, md5, 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.


Note


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.


When multiple transforms are configured for a transform type, the order of priority is from left to right.

A proposal with multiple transforms for each transform type translates to all possible combinations of transforms. If only a subset of these combinations is required, then they must be configured as individual proposals.

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

For example, the commands shown above translate to the following transform combinations:

aes-cbc-128, sha1, 14
aes-cbc-192, sha1, 14
aes-cbc-128, sha256, 14
aes-cbc-192, sha256, 14

To configure the first and last transform combinations, use the following commands:

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
Device(config-ikev2-proposal)# exit
Device(config)# crypto ikev2 proposal proposal-2
Device(config-ikev2-proposal)# encryption aes-cbc-192
Device(config-ikev2-proposal)# integrity sha256
Device(config-ikev2-proposal)# group 14

Transform Sets: A Combination of Security Protocols and Algorithms

About Transform Sets


Note


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.

You can specify multiple transform sets, and then specify one or more of these transform sets in a crypto map entry. The transform set defined in the crypto map entry is used in the IPsec SA negotiation to protect the data flows specified by that crypto map entry’s access list.

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.)

If you change a transform set definition, the change is only applied to crypto map entries that reference the transform set. The change is not applied to existing security associations, but is used in subsequent negotiations to establish new SAs.

The table below shows allowed transform combinations.

Table 1 Allowed Transform Combinations

Transform Type

Transform

Description

AH Transform (Pick only one.)

ah-md5-hmac

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

ah-sha-hmac

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

A transform set combination of AH and ESP is not supported in Cisco IOS XE releases.

ESP Encryption Transform (Pick only one.)

esp-aes

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

esp-gcm

esp-gmac

The esp-gcm and esp-gmac transforms are ESPs with either a 128-bit or a 256-bit encryption algorithm. The default for either of these transforms is 128 bits.

Both esp-gcm and esp-gmac transforms cannot be configured together with any other ESP transform within the same crypto IPsec transform set using the crypto ipsec transform-set command.

The esp-gcm and esp-gmac combinations are not supported on the following:

  • ASR1001

  • ESP-5

  • ESP-10

  • ESP-20

  • ESP-40

esp-aes 192

ESP with the 192-bit AES encryption algorithm.

esp-aes 256

ESP with the 256-bit AES encryption algorithm.

esp-des

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

esp-3des

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

esp-null

Null encryption algorithm.

ESP Authentication Transform (Pick only one.)

esp-md5-hmac

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

esp-sha-hmac

ESP with the SHA (HMAC variant) authentication algorithm.

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

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.

Suite-B is not supported on the following hardware platforms:
  • ASR1001

  • ESP-5

  • ESP-10

  • ESP-20

  • ESP-40

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

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.

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
     Command or ActionPurpose
    Step 1 enable


    Example:
    Device> enable
     

    Enables privileged EXEC mode.

    • Enter your password if prompted.

     
    Step 2 configure terminal


    Example:
    Device# configure terminal
     

    Enters global configuration mode.

     
    Step 3 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.

     
    Step 4 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.)

     
    Step 5 end


    Example:
    Device(cfg-crypto-tran)# end
     

    Exits crypto transform configuration mode and enters privileged EXEC mode.

     
    Step 6 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.

     
    Step 7 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 the “Creating 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
       Command or ActionPurpose
      Step 1 enable


      Example:
      Device> enable
       

      Enables privileged EXEC mode.

      • Enter your password if prompted.

       
      Step 2 configure terminal


      Example:
      Device# configure terminal
       

      Enters global configuration mode.

       
      Step 3 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.

       
      Step 4 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).

       
      Step 5 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.)

       
      Step 6 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.

       
      Step 7 end


      Example:
      Device(config-ikev2-proposal)# end
       

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

       
      Step 8 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
      Device(config)# crypto ikev2 proposal proposal-2
      Device(config-ikev2-proposal)# encryption aes-cbc-128 aes-cbc-192
      Device(config-ikev2-proposal)# integrity sha2 sha256
      Device(config-ikev2-proposal)# group 14 15
      

      The IKEv2 proposal proposal-2 translates to the following prioritized list of transform combinations:

      • aes-cbc-128, sha1, 14

      • aes-cbc-128, sha1, 15

      • aes-cbc-128, sha256, 14

      • aes-cbc-128, sha256, 15

      • aes-cbc-192, sha1, 14

      • aes-cbc-192, sha1, 15

      • aes-cbc-192, sha256, 14

      • aes-cbc-192, sha256, 15

      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.

      Configuring an IPsec Profile

      Before You Begin

      Do we have any Prerequisites?

      SUMMARY STEPS

        1.    configure terminal

        2.    crypto ipsec profile profile1

        3.    set transform-set tset1

        4.    end


      DETAILED STEPS
        Step 1   configure terminal
        Step 2   crypto ipsec profile profile1

        Defines the IPsec parameters that are to be used for IPsec encryption between two IPsec devices, and enters IPsec profile configuration mode.

        Step 3   set transform-set tset1

        Specifies which transform sets can be used with the crypto map entry.

        Step 4   end

        What to Do Next

        After configuring an IPsec profile, you will have to assign the profile to a Provide Link or virtual tunnel interface.

        Configuration Examples for IPsec VPN

        Additional References for Configuring Security for VPNs with IPsec

        Related Documents

        Related Topic

        Document Title

        Cisco IOS commands

        Cisco IOS Master Commands List, All Releases

        IKE, IPsec, and PKI configuration commands: complete command syntax, command mode, defaults, usage guidelines, and examples

        IKE configuration

        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

        • Configuring Internet Key Exchange for IPsec VPNs

        • Configuring Internet Key Exchange Version 2 (IKEv2) and FlexVPN Site-to-Site

        Suite-B support for certificate enrollment for a PKI

        Configuring Certificate Enrollment for a PKI

        Recommended cryptographic algorithms

        Next Generation Encryption

        Standards

        Standards

        Title

        None

        MIBs

        MIBs

        MIBs Link

        • CISCO-IPSEC-FLOW-MONITOR- MIB

        • CISCO-IPSEC-MIB

        • CISCO-IPSEC-POLICY-MAP-MIB

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

        http://www.cisco.com/go/mibs

        RFCs

        RFCs

        Title

        RFC 2401

        Security Architecture for the Internet Protocol

        RFC 2402

        IP Authentication Header

        RFC 2403

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

        RFC 2404

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

        RFC 2405

        The ESP DES-CBC Cipher Algorithm With Explicit IV

        RFC 2406

        IP Encapsulating Security Payload (ESP)

        RFC 2407

        The Internet IP Security Domain of Interpretation for ISAKMP

        RFC 2408

        Internet Security Association and Key Management Protocol (ISAKMP)

        Technical Assistance

        Description

        Link

        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.

        http:/​/​www.cisco.com/​cisco/​web/​support/​index.html

        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.

        Table 2 Feature Information for Configuring Security for IPsec VPNs

        Feature Name

        Software Releases

        Feature Information

        Advanced Encryption Standard

        Cisco IOS XE Release 2.1

        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.

        IKE Shared Secret Using AAA Server

        Cisco IOS XE Release 2.1

        The IKE Shared Secret Using AAA Server feature enables key lookup from a AAA server.

        In Cisco IOS XE Release 2.1, this feature was implemented on Cisco ASR 1000 Series Aggregation Services Routers.

        Suite-B Support in IOS SW Crypto

        Cisco IOS XE Release 3.7S

        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.

        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.