Use the Cisco Security feature template for all Cisco IOS XE Catalyst SD-WAN devices. On the edge routers and on Cisco SD-WAN Validator, use this template to configure IPsec for data plane security. On Cisco SD-WAN Manager and Cisco SD-WAN Controller, use the Security feature template to configure DTLS or TLS for control plane security.

Configure Security Parameters

1. From the Cisco SD-WAN Manager menu, choose Configuration > Templates.

2. Click Feature Templates and then click Add Template.

   Note	In Cisco vManage Release 20.7.1 and earlier releases, Feature Templates is called Feature.

3. From the Devices list in the left pane, choose a device.

   The templates applicable to the selected device appear in the right pane.

4. Click Cisco Security to open the template.

5. In the Template Name field, enter a name for the template. The name can be up to 128 characters and can contain only alphanumeric characters.

6. In the Template Description field, enter a description of the template. The description can be up to 2048 characters and can contain only alphanumeric characters.

When you first open a feature template, for each parameter that has a default value, the scope is set to Default (indicated by a check mark), and the default setting or value is shown. To change the default or to enter a value, click the scope drop-down menu to the left of the parameter field and choose one of the following:

Configure Control Plane Security

Note	The Configure Control Plane Security section is applicable to Cisco SD-WAN Manager and Cisco SD-WAN Controller only.

To configure the control plane connection protocol on a Cisco SD-WAN Manager instance or a Cisco SD-WAN Controller, choose the Basic Configuration area and configure the following parameters:

Click Save

Configure Data Plane Security

Configure various data plane security parameters under the relevant areas of the template:

Key Chain and Key ID

To add a new key chain, click New Key Chain and specify the following:

Click Save.

Authentication Types in Cisco IOS XE Catalyst SD-WAN Release 17.6.1a and Later

From Cisco IOS XE Catalyst SD-WAN Release 17.6.1a Cisco SD-WAN Release 20.6.1, the following integrity types are supported:

• esp: This option enables Encapsulating Security Payload (ESP) encryption and integrity checking on the ESP header.

• ip-udp-esp: This option enables ESP encryption. In addition to the integrity checks on the ESP header and the payload, the checks also include the outer IP and UDP headers.

• ip-udp-esp-no-id: This option is is similar to ip-udp-esp, however, the ID field of the outer IP header is ignored. Configure this option in the list of integrity types to have the Cisco Catalyst SD-WAN software ignore the ID field in the IP header so that the Cisco Catalyst SD-WAN can work in conjunction with non-Cisco devices.

• none: This option turns integrity checking off on IPSec packets. We don't recommend using this option.

By default, IPsec tunnel connections use an enhanced version of the Encapsulating Security Payload (ESP) protocol for authentication. To modify the negotiated interity types, use the following command:

security ipsec integrity-type { none | ip-udp-esp | ip-udp-esp-no-id | esp }

Authentication Types Before Cisco IOS XE Catalyst SD-WAN Release 17.6.1a

By default, IPsec tunnel connections use an enhanced version of the Encapsulating Security Payload (ESP) protocol for authentication. To modify the negotiated authentication types, use the following command:

Device(config)# security ipsec authentication-type (ah-sha1-hmac | ah-no-id | sha1-hmac | )

By default, IPsec tunnel connections use AES-GCM-256, which provides both encryption and authentication.

Configure each authentication type with a separate security ipsec authentication-type command. The command options map to the following authentication types, which are listed in order from most strong to least strong:

Note

The sha1 in the configuration options is used for historical reasons. The authentication options indicate over how much of the packet integrity checking is done. They do not specify the algorithm that checks the integrity. The authentication algorithms supported by Cisco Catalyst SD-WAN do not use SHA1.

• ah-sha1-hmac enables encryption and encapsulation using ESP. However, in addition to the integrity checks on the ESP header and payload, the checks also include the outer IP and UDP headers. Hence, this option supports an integrity check of the packet similar to the Authentication Header (AH) protocol. All integrity and encryption is performed using AES-256-GCM.

• ah-no-id enables a mode that is similar to ah-sha1-hmac, however the ID field of the outer IP header is ignored. This option accommodates some non-Cisco Catalyst SD-WAN devices, including the Apple AirPort Express NAT, that have a bug that causes the ID field in the IP header, a non-mutable field, to be modified. Configure the ah-no-id option in the list of authentication types to have the Cisco Catalyst SD-WAN AH software ignore the ID field in the IP header so that the Cisco Catalyst SD-WAN software can work in conjunction with these devices.

• sha1-hmac enables ESP encryption and integrity checking.

For information about which data packet fields are affected by these authentication types, see Data Plane Integrity.

Cisco IOS XE Catalyst SD-WAN devices and Cisco vEdge devices advertise their configured authentication types in their TLOC properties. The two routers on either side of an IPsec tunnel connection negotiate the authentication to use on the connection between them, using the strongest authentication type that is configured on both of the routers. For example, if one router advertises the ah-sha1-hmac and ah-no-id types, and a second router advertises the ah-no-id type, the two routers negotiate to use ah-no-id on the IPsec tunnel connection between them. If no common authentication types are configured on the two peers, no IPsec tunnel is established between them.

For the unicast traffic, the encryption algorithm on IPSec tunnel connections is AES-256-GCM. From Cisco IOS XE SD-WAN Release 17.2.1r, the multicast traffic also supports AES-256-GCM encryption algorithm. You cannot modify the encryption algorithm choice made by the software.

When the IPsec authentication type is changed, the AES key for the data path is changed.

CLI Equivalent

crypto
   ipsec
      profile ipsec_profile_name
         set ikev2-profile ikev2_profile_name
         set security-association
            lifetime {seconds 120-2592000 | kilobytes disable}  
            replay {disable | window-size {64 | 128 | 256 | 512 | 1024 | 4096 | 8192}
         set pfs group {2 | 14 | 15 | 16 | none}
         set transform-set transform_set_name

CLI Equivalent

crypto
   ikev2
      profile ikev2_profile_name
         dpd 10-3600 2-60 {on-demand | periodic}

IKE Version 1 and IKE Version 2

To configure the IPsec tunnel that carries IKEv1 and IKEv2 traffic, click IPSEC and configure the following parameters:

To save the feature template, click Save.

Change the IKE Version from IKEv1 to IKEv2

To change the IKE version, do the following:

1. From the Cisco SD-WAN Manager menu, choose Configuration > Templates.

2. Click Feature Templates, and then click Add Template.

   Note	In Cisco vManage Release 20.7.x and earlier releases, Feature Templates is called Feature.

3. Choose the device for which you are creating the template.

4. Click Basic Configuration.

5. Use the shutdown parameter with the yes option (yes shutdown) to shut down the tunnel.

6. Remove the ISAKMP profile from the IPsec profile.

7. Attach the IKEv2 profile with the IPsec profile.

   Note	Perform this step if you already have an IKEv2 profile. Otherwise, create an IKEv2 profile first.

8. Use the shutdown parameter with the no option (no shutdown) to start up the tunnel.

   Note	You must issue the shutdown operations in two separate operations.

Note	There is no single CLI for changing the IKE version. You need to follow the sequence of steps listed in the Change the IKE Version from IKEv1 to IKEv2 section.

CLI Equivalents for IKEv1

ISAKMP CLI Configuration for IKEv1

crypto
   isakmp
      keepalive 60-86400 2-60 {on-demand | periodic}
      policy policy_num
         encryption {AES128-CBC-SHA1 | AES256-CBC-SHA1}
         hash {sha384 | sha256 | sha}
         authentication pre-share
         group {2 | 14 | 16 | 19 | 20 | 21}
         lifetime 60-86400
      profile ikev1_profile_name
         match identity address ip_address [mask]
         keyring keyring_name

IPsec CLI Configuration for IKEv1

profile ipsec_profile_name
         set transform-set transform_set_name
         set isakmp-profile ikev1_profile_name
         set security-association
            lifetime {kilobytes disable | seconds 120-2592000}
            replay {disable | window-size [64 | 128 | 256 | 512 | 1024]}
         set pfs group {14 | 16 | 19 | 20 | 21}
   keyring keyring_name
      pre-shared-key address ip_address [mask] key key_string
   ipsec transform-set transform_set_name {esp-gcm 256 | esp-aes 256 [esp-sha384-hmac | esp-sha256-hmac] mode tunnel

Summary Steps

1. enable

2. configure terminal

3. crypto isakmp policy priority

4. encryption {des | 3des | aes | aes 192 | aes 256 }

5. hash {sha | sha256 | sha384 | md5 }

6. authentication {rsa-sig | rsa-encr | pre-share }

7. group {1 | 2 | 5 | 14 | 15 | 16 | 19 | 20 | 24 }

8. lifetime seconds

9. exit

10. exit

CLI Equivalent for IKE2

crypto
   ikev2
      proposal proposal_name
         encryption {3des | aes-cbc-128 | aes-cbc-192 | aes-cbc-256 | des}
         integrity {sha256 | sha384 | sha512}
         group {2 | 14 | 15 | 16}
      keyring idev2_keyring_name
         peer peer_name
         address tunnel_dest_ip [mask]
         pre-shared-key key_string
      profile ikev2_profile_name
         match identity remote address ip_address
         authentication {remote | local} pre-share
         keyring local ikev2_keyring_name
         lifetime 120-86400