09-Security Configuration Guide

HomeSupportResource CenterSwitchesH3C S6300 Switch SeriesH3C S6300 Switch SeriesTechnical DocumentsConfigureConfiguration GuidesH3C S6300 Switch Series Configuration Guides-Release 243x-6W10009-Security Configuration Guide
09-IPsec configuration
Title Size Download
09-IPsec configuration 536.27 KB

Contents

Configuring IPsec· 1

Overview· 1

Security protocols and encapsulation modes· 1

Security association· 3

Authentication and encryption· 3

IPsec implementation· 4

Protocols and standards· 5

FIPS compliance· 5

IPsec tunnel establishment 5

Implementing ACL-based IPsec· 6

Feature restrictions and guidelines· 6

ACL-based IPsec configuration task list 6

Configuring an ACL· 7

Configuring an IPsec transform set 7

Configuring a manual IPsec policy· 9

Configuring an IKE-based IPsec policy· 11

Applying an IPsec policy to an interface· 15

Enabling ACL checking for de-encapsulated packets· 16

Configuring IPsec anti-replay· 16

Configuring IPsec anti-replay redundancy· 16

Binding a source interface to an IPsec policy· 17

Enabling QoS pre-classify· 18

Enabling logging of IPsec packets· 18

Configuring the DF bit of IPsec packets· 19

Configuring IPsec for IPv6 routing protocols· 19

Configuration task list 19

Configuring a manual IPsec profile· 20

Configuring SNMP notifications for IPsec· 21

Displaying and maintaining IPsec· 22

IPsec configuration examples· 22

Configuring a manual mode IPsec tunnel for IPv4 packets· 22

Configuring an IKE-based IPsec tunnel for IPv4 packets· 25

Configuring IPsec for RIPng· 27

Configuring IKE· 32

Overview· 32

IKE negotiation process· 32

IKE security mechanism·· 33

Protocols and standards· 34

FIPS compliance· 34

IKE configuration prerequisites· 34

IKE configuration task list 34

Configuring an IKE profile· 35

Configuring an IKE proposal 37

Configuring an IKE keychain· 38

Configuring the global identity information· 39

Configuring the IKE keepalive feature· 40

Configuring the IKE NAT keepalive feature· 40

Configuring IKE DPD·· 40

Enabling invalid SPI recovery· 41

Setting the maximum number of IKE SAs· 42

Configuring SNMP notifications for IKE· 42

Displaying and maintaining IKE· 43

IKE configuration examples· 43

Main mode IKE with pre-shared key authentication configuration example· 43

Verifying the configuration· 45

Troubleshooting IKE· 46

IKE negotiation failed because no matching IKE proposals were found· 46

IKE negotiation failed because no IKE proposals or IKE keychains are specified correctly· 46

IPsec SA negotiation failed because no matching IPsec transform sets were found· 47

IPsec SA negotiation failed due to invalid identity information· 47

Configuring IKEv2· 51

Overview· 51

IKEv2 negotiation process· 51

New features in IKEv2· 52

Protocols and standards· 52

Feature and software version compatibility· 53

IKEv2 configuration task list 53

Configuring an IKEv2 profile· 53

Configuring an IKEv2 policy· 56

Configuring an IKEv2 proposal 57

Configuring an IKEv2 keychain· 58

Configure global IKEv2 parameters· 59

Enabling the cookie challenging feature· 59

Configuring the IKEv2 DPD feature· 59

Configuring the IKEv2 NAT keepalive feature· 60

Displaying and maintaining IKEv2· 60

IKEv2 configuration examples· 61

IKEv2 with pre-shared key authentication configuration example· 61

IKEv2 with RSA signature authentication configuration example· 64

Troubleshooting IKEv2· 68

IKEv2 negotiation failed because no matching IKEv2 proposals were found· 68

IPsec SA negotiation failed because no matching IPsec transform sets were found· 69

IPsec tunnel establishment failed· 69

 


Configuring IPsec

CAUTION

CAUTION:

ACLs for IPsec take effect only on traffic that is generated by the device and traffic that is destined for the device. They do not take effect on traffic forwarded through the device.

 

Overview

IP Security (IPsec) is defined by the IETF to provide interoperable, high-quality, cryptographically-based security for IP communications. It is a Layer 3 VPN technology that transmits data in a secure channel established between two endpoints (such as two security gateways). Such a secure channel is usually called an IPsec tunnel.

IPsec is a security framework that has the following protocols and algorithms:

·           Authentication Header (AH).

·           Encapsulating Security Payload (ESP).

·           Internet Key Exchange (IKE).

·           Algorithms for authentication and encryption.

AH and ESP are security protocols that provide security services. IKE performs automatic key exchange. For more information about IKE, see "Configuring IKE."

IPsec provides the following security services for data packets in the IP layer:

·           Confidentiality—The sender encrypts packets before transmitting them over the Internet, protecting the packets from being eavesdropped en route.

·           Data integrity—The receiver verifies the packets received from the sender to make sure they are not tampered with during transmission.

·           Data origin authentication—The receiver verifies the authenticity of the sender.

·           Anti-replay—The receiver examines packets and drops outdated and duplicate packets.

IPsec delivers the following benefits:

·           Reduced key negotiation overhead and simplified maintenance by supporting the IKE protocol. IKE provides automatic key negotiation and automatic IPsec security association (SA) setup and maintenance.

·           Good compatibility. You can apply IPsec to all IP-based application systems and services without modifying them.

·           Encryption on a per-packet rather than per-flow basis. Per-packet encryption allows for flexibility and greatly enhances IP security.

Security protocols and encapsulation modes

Security protocols

IPsec comes with two security protocols, AH and ESP. They define how to encapsulate IP packets and the security services that they can provide.

·           AH (protocol 51) defines the encapsulation of the AH header in an IP packet, as shown in Figure 3. AH can provide data origin authentication, data integrity, and anti-replay services to prevent data tampering, but it cannot prevent eavesdropping. Therefore, it is suitable for transmitting non-confidential data. AH supports authentication algorithms HMAC-MD5 and HMAC-SHA1.

·           ESP (protocol 50) defines the encapsulation of the ESP header and trailer in an IP packet, as shown in Figure 3. ESP can provide data encryption, data origin authentication, data integrity, and anti-replay services. Unlike AH, ESP can guarantee data confidentiality because it can encrypt the data before encapsulating the data to IP packets. ESP supports encryption algorithms such as DES, 3DES, and AES, and authentication algorithms HMAC-MD5 and HMAC-SHA1.

Both AH and ESP provide authentication services, but the authentication service provided by AH is stronger. In practice, you can choose either or both security protocols. When both AH and ESP are used, an IP packet is encapsulated first by ESP and then by AH.

Encapsulation modes

IPsec supports the following encapsulation modes:

·           Transport mode—The security protocols protect the upper layer data of an IP packet. Only the transport layer data is used to calculate the security protocol headers. The calculated security protocol headers and the encrypted data (only for ESP encapsulation) are placed after the original IP header. You can use the transport mode when end-to-end security protection is required (the secured transmission start and end points are the actual start and end points of the data). The transport mode is typically used for protecting host-to-host communications, as shown in Figure 1.

Figure 1 IPsec protection in transport mode

 

·           Tunnel mode—The security protocols protect the entire IP packet. The entire IP packet is used to calculate the security protocol headers. The calculated security protocol headers and the encrypted data (only for ESP encapsulation) are encapsulated in a new IP packet. In this mode, the encapsulated packet has two IP headers. The inner IP header is the original IP header. The outer IP header is added by the network device that provides the IPsec service. You must use the tunnel mode when the secured transmission start and end points are not the actual start and end points of the data packets (for example, when two gateways provide IPsec but the data start and end points are two hosts behind the gateways). The tunnel mode is typically used for protecting gateway-to-gateway communications, as shown in Figure 2.

Figure 2 IPsec protection in tunnel mode

 

Figure 3 shows how the security protocols encapsulate an IP packet in different encapsulation modes.

Figure 3 Security protocol encapsulations in different modes

 

Security association

A security association (SA) is an agreement negotiated between two communicating parties called IPsec peers. An SA comprises the following parameters for data protection:

·           Security protocols (AH, ESP, or both).

·           Encapsulation mode (transport mode or tunnel mode).

·           Authentication algorithm (HMAC-MD5 or HMAC-SHA1).

·           Encryption algorithm (DES, 3DES, or AES).

·           Shared keys and their lifetimes.

An SA is unidirectional. At least two SAs are needed to protect data flows in a bidirectional communication. If two peers want to use both AH and ESP to protect data flows between them, they construct an independent SA for each protocol in each direction.

An SA is uniquely identified by a triplet, which consists of the security parameter index (SPI), destination IP address, and security protocol identifier. An SPI is a 32-bit number that identifies an SA. It is transmitted in the AH/ESP header.

An SA can be set up manually or through IKE.

·           Manual mode—Configure all parameters for the SA through commands. This configuration mode is complex and does not support some advanced features (such as periodic key update), but it can implement IPsec without IKE. This mode is mainly used in small and static networks or when the number of IPsec peers in the network is small.

·           IKE negotiation mode—The peers negotiate and maintain the SA through IKE. This configuration mode is simple and has good expansibility. As a best practice, set up SAs through IKE negotiations in medium- and large-scale dynamic networks.

A manually configured SA never ages out. An IKE-created SA has a lifetime, which comes in two types:

·           Time-based lifetime—Defines how long the SA can be valid after it is created.

·           Traffic-based lifetime—Defines the maximum traffic that the SA can process.

If both lifetime timers are configured for an SA, the SA becomes invalid when either of the lifetime timers expires. Before the SA expires, IKE negotiates a new SA, which takes over immediately after its creation.

Authentication and encryption

Authentication algorithms

IPsec uses hash algorithms to perform authentication. A hash algorithm produces a fixed-length digest for an arbitrary-length message. IPsec peers respectively calculate message digests for each packet. The receiver compares the local digest with that received from the sender. If the digests are identical, the receiver considers the packet intact and the sender's identity valid. IPsec uses the Hash-based Message Authentication Code (HMAC) based authentication algorithms, including HMAC-MD5 and HMAC-SHA1. Compared with HMAC-SHA1, HMAC-MD5 is faster but less secure.

Encryption algorithms

IPsec uses symmetric encryption algorithms, which encrypt and decrypt data by using the same keys. The following encryption algorithms are available for IPsec on the device:

·           DES—Encrypts a 64-bit plaintext block with a 56-bit key. DES is the least secure but the fastest algorithm.

·           3DES—Encrypts plaintext data with three 56-bit DES keys. The key length totals up to 168 bits. It provides moderate security strength and is slower than DES.

·           AES—Encrypts plaintext data with a 128-bit, 192-bit, or 256-bit key. AES provides the highest security strength and is slower than 3DES.

IPsec implementation

To implement IPsec protection for packets between two peers, complete the following tasks on each peer:

·           Configure an IPsec policy, which defines the range of packets to be protected by IPsec and the security parameters used for the protection.

·           Apply the IPsec policy to an interface or an application.

When you apply an IPsec policy to an interface, you implement IPsec based on the interface. Packets received and sent by the interface are protected according to the IPsec policy. When you apply an IPsec policy to an application, you implement IPsec based on the application. Packets of the application are protected according to the IPsec policy, regardless of the receiving and sending interface of the packets.

IPsec protects packets as follows:

·           When an IPsec peer identifies the packets to be protected according to the IPsec policy, it sets up an IPsec tunnel and sends the packet to the remote peer through the tunnel. The IPsec tunnel can be manually configured beforehand, or it can be set up through IKE negotiation triggered by the packet. The IPsec tunnels are actually the IPsec SAs. The inbound packets are protected by the inbound SA, and the outbound packets are protected by the outbound SA.

·           When the remote IPsec peer receives the packet, it drops, de-encapsulates, or directly forwards the packet according to the configured IPsec policy.

Interface-based IPsec supports setting up IPsec tunnels based on ACLs.

ACL-based IPsec

To implement ACL-based IPsec, configure an ACL to define the data flows to be protected, reference the ACL in an IPsec policy, and then apply the IPsec policy to an interface. When packets sent by the interface match the permit rule of the ACL, the packets are protected by the outbound IPsec SA and encapsulated with IPsec. When the interface receives an IPsec packet whose destination address is the IP address of the local device, it searches for the inbound IPsec SA according to the SPI carried in the IPsec packet header for de-encapsulation. If the de-encapsulated packet matches the permit rule of the ACL, the device processes the packet. Otherwise, it drops the packet.

The device supports the following data flow protection modes:

·           Standard mode—One IPsec tunnel protects one data flow. The data flow permitted by an ACL rule is protected by one IPsec tunnel that is established solely for it.

·           Aggregation mode—One IPsec tunnel protects all data flows permitted by all the rules of an ACL. This mode is only used to communicate with old-version devices.

·           Per-host mode—One IPsec tunnel protects one host-to-host data flow. One host-to-host data flow is identified by one ACL rule and protected by one IPsec tunnel established solely for it. This mode consumes more system resources when multiple data flows exist between two subnets to be protected.

Application-based IPsec

This IPsec implementation method does not require an ACL. All packets of the application bound to an IPsec profile are encapsulated with IPsec, and all packets of the applications that are not bound with IPsec and the IPsec packets that failed to be de-encapsulated are dropped.

You can use IPsec to protect an IPv6 routing protocol by using this method. The supported IPv6 routing protocols include OSPFv3, IPv6 BGP, and RIPng.

In one-to-many communication scenarios, you must configure the IPsec SAs for an IPv6 routing protocol in manual mode because of the following reasons:

·           The automatic key exchange mechanism is used only to protect communications between two points. In one-to-many communication scenarios, automatic key exchange cannot be implemented.

·           One-to-many communication scenarios require that all the devices use the same SA parameters (SPI and key) to receive and send packets. IKE negotiated SAs cannot meet this requirement.

Protocols and standards

·           RFC 2401, Security Architecture for the Internet Protocol

·           RFC 2402, IP Authentication Header

·           RFC 2406, IP Encapsulating Security Payload

·           RFC 4552, Authentication/Confidentiality for OSPFv3

FIPS compliance

The device supports the FIPS mode that complies with NIST FIPS 140-2 requirements. Support for features, commands, and parameters might differ in FIPS mode (see "Configuring FIPS") and non-FIPS mode.

IPsec tunnel establishment

IPsec tunnels can be established in different methods. Choose a correct method to establish IPsec tunnels according to your network conditions:

·           ACL-based IPsec tunnel—Protects packets identified by an ACL. To establish an ACL-based IPsec tunnel, configure an IPsec policy, reference an ACL in the policy, and apply the policy to an interface (see "Implementing ACL-based IPsec"). The IPsec tunnel establishment steps are the same in an IPv4 network and in an IPv6 network.

·           Application-based IPsec tunnel—Protects the packets of an application. This method can be used to protect IPv6 routing protocols. It does not require an ACL. To establish application-based IPsec tunnels, configure manual IPsec profiles and bind the profiles to an IPv6 routing protocol. For more information about IPv6 routing protocols, see "Configuring IPsec for IPv6 routing protocols."

Implementing ACL-based IPsec

Feature restrictions and guidelines

ACLs for IPsec take effect only on traffic that is generated by the device and traffic that is destined for the device. They do not take effect on traffic forwarded through the device. For example, an ACL-based IPsec tunnel can protect log messages the device sends to a log server, but it cannot protect all the data flows and voice flows that are forwarded by the device. For more information about configuring an ACL for IPsec, see "Configuring an ACL."

Typically, IKE uses UDP port 500 for communication, and AH and ESP use the protocol numbers 51 and 50. Make sure traffic of these protocols is not denied on the interfaces with IKE or IPsec configured.

ACL-based IPsec configuration task list

Use the following procedure to implement ACL-based IPsec:

1.      Configure an ACL for identifying data flows to be protected. To use IPsec to protect VPN traffic, you do not need to specify the VPN parameters in the ACL rules.

2.      Configure IPsec transform sets to specify the security protocols, authentication and encryption algorithms, and the encapsulation mode.

3.      Configure an IPsec policy to associate data flows with the IPsec transform sets, specify the SA negotiation mode, the peer IP addresses (the start and end points of the IPsec tunnel), the required keys, and the SA lifetime.

An IPsec policy is a set of IPsec policy entries that have the same name but different sequence numbers. In the same IPsec policy, an IPsec policy entry with a smaller sequence number has a higher priority.

4.      Apply the IPsec policy to an interface.

Complete the following tasks to configure ACL-based IPsec:

 

Tasks at a glance

(Required.) Configuring an ACL

(Required.) Configuring an IPsec transform set

(Required.) Configure an IPsec policy (use either method):

·          Configuring a manual IPsec policy

·          Configuring an IKE-based IPsec policy

(Required.) Applying an IPsec policy to an interface

(Optional.) Enabling ACL checking for de-encapsulated packets

(Optional.) Configuring IPsec anti-replay

(Optional.) Configuring IPsec anti-replay redundancy

(Optional.) Binding a source interface to an IPsec policy

(Optional.) Enabling QoS pre-classify

(Optional.) Enabling logging of IPsec packets

(Optional.) Configuring the DF bit of IPsec packets

(Optional.) Configuring SNMP notifications for IPsec

 

Configuring an ACL

IPsec uses ACLs to identify the traffic to be protected.

Keywords in ACL rules

An ACL is a collection of ACL rules. Each ACL rule is a deny or permit statement. A permit statement identifies a data flow protected by IPsec, and a deny statement identifies a data flow that is not protected by IPsec. IPsec compares a packet against the referenced ACL rules and processes the packet according to the first rule it matches.

·           Each ACL rule matches both the outbound traffic and the returned inbound traffic.

·           In the outbound direction, if a permit statement is matched, IPsec considers that the packet requires protection and continues to process it. If a deny statement is matched or no match is found, IPsec considers that the packet does not require protection and delivers it to the next feature module.

·           In the inbound direction:

¡  Non-IPsec packets that match a permit statement are dropped.

¡  IPsec packets destined for the device itself are de-encapsulated. By default, the de-encapsulated packets are compared against the ACL rules. Only those that match a permit statement are processed. Other packets are dropped. If ACL checking for de-encapsulated packets is disabled, the de-encapsulated packets are not compared against the ACL rules and are directly processed by other modules.

When defining ACL rules for IPsec, follow these guidelines:

·           Permit only data flows that need to be protected and use the any keyword with caution. With the any keyword specified in a permit statement, all outbound traffic matching the permit statement will be protected by IPsec. All inbound IPsec packets matching the permit statement will be received and processed, but all inbound non-IPsec packets will be dropped. This will cause all the inbound traffic that does not need IPsec protection to be dropped.

·           Avoid statement conflicts in the scope of IPsec policy entries. When creating a deny statement, be careful with its matching scope and matching order relative to permit statements. The policy entries in an IPsec policy have different match priorities. ACL rule conflicts between them are prone to cause mistreatment of packets. For example, when configuring a permit statement for an IPsec policy entry to protect an outbound traffic flow, you must avoid the situation that the traffic flow matches a deny statement in a higher priority IPsec policy entry. Otherwise, the packets will be sent out as normal packets. If they match a permit statement at the receiving end, they will be dropped by IPsec.

Mirror image ACLs

To make sure SAs can be set up and the traffic protected by IPsec can be processed correctly between two IPsec peers, create mirror image ACLs on the IPsec peers.

Configuring an IPsec transform set

An IPsec transform set, part of an IPsec policy, defines the security parameters for IPsec SA negotiation, including the security protocol, encryption algorithms, and authentication algorithms.

Changes to an IPsec transform set affect only SAs negotiated after the changes. To apply the changes to existing SAs, execute the reset ipsec sa command to clear the SAs so that they can be set up by using the updated parameters.

To configure an IPsec transform set:

 

Step

Command

Remarks

1.      Enter system view.

system-view

N/A

2.      Create an IPsec transform set and enter its view.

ipsec transform-set transform-set-name

By default, no IPsec transform set exists.

3.      Specify the security protocol for the IPsec transform set.

protocol { ah | ah-esp | esp }

Optional.

By default, the IPsec transform set uses ESP as the security protocol.

4.      Specify the ESP encryption algorithm.

·          In non-FIPS mode:
esp encryption-algorithm { 3des-cbc | aes-cbc-128 | aes-cbc-192 | aes-cbc-256 | aes-ctr-128 | aes-ctr-192 | aes-ctr-256 | camellia-cbc-128 | camellia-cbc-192 | camellia-cbc-256 | des-cbc | gmac-128 | gmac-192 | gmac-256 | gcm-128 | gcm-192 | gcm-256 | null } *

·          In FIPS mode:
esp encryption-algorithm aes-cbc-128 | aes-cbc-192 | aes-cbc-256 | aes-ctr-128 | aes-ctr-192 | aes-ctr-256 | gmac-128 | gmac-192 | gmac-256 | gcm-128 | gcm-192 | gcm-256 } *

By default, no ESP encryption algorithm is specified.

Required when you select ESP or AH-ESP as the security protocol.

If you use ESP in FIPS mode, you must specify both the ESP encryption algorithm and the ESP authentication algorithm.

You can specify multiple algorithms by using one command, and the algorithm specified earlier has a higher priority.

The aes-ctr-128, aes-ctr-192, aes-ctr-256, camellia-cbc-128, camellia-cbc-192, camellia-cbc-256, gmac-128, gmac-192, gmac-256, gcm-128, gcm-192, and gcm-256 encryption algorithms are available only for IKEv2.

5.      Specify the ESP authentication algorithm.

·          In non-FIPS mode:
esp authentication-algorithm { aes-xcbc-mac | md5 | sha1 | sha256 | sha384 | sha512 } *

·          In FIPS mode:
esp authentication-algorithm { sha1 | sha256 | sha384 | sha512 } *

By default, no ESP authentication algorithm is specified.

Required when you select ESP or AH-ESP as the security protocol.

If you use ESP in FIPS mode, you must specify both the ESP encryption algorithm and the ESP authentication algorithm.

You can specify multiple algorithms by using one command, and the algorithm specified earlier has a higher priority.

The aes-xcbc-mac, sha256, sha384, and sha512 authentication algorithms are available only for IKEv2.

6.      Specify the AH authentication algorithm.

·          In non-FIPS mode:
ah authentication-algorithm { aes-xcbc-mac | md5 | sha1 | sha256 | sha384 | sha512 } *

·          In FIPS mode:
ah authentication-algorithm { sha1 | sha256 | sha384 | sha512 } *

By default, no AH authentication algorithm is specified.

Required when you select AH or AH-ESP as the security protocol.

You can specify multiple algorithms by using one command, and the algorithm specified earlier has a higher priority.

The aes-xcbc-mac, sha256, sha384, and sha512 authentication algorithms are available only for IKEv2.

7.      Specify the mode in which the security protocol encapsulates IP packets.

encapsulation-mode { transport | tunnel }

By default, the security protocol encapsulates IP packets in tunnel mode.

The transport mode applies only when the source and destination IP addresses of data flows match those of the IPsec tunnel.

IPsec for IPv6 routing protocols supports only the transport mode.

8.      (Optional.) Enable the Perfect Forward Secrecy (PFS) feature for the IPsec policy.

·          In non-FIPS mode:
pfs
{ dh-group1 | dh-group2 | dh-group5 | dh-group14 | dh-group19 | dh-group20 | dh-group24 }

·          In FIPS mode:
pfs
{ dh-group14 | dh-group24 | dh-group19 | dh-group20 }

By default, the PFS feature is not used for SA negotiation.

For more information about PFS, see "Configuring IKE."

The security level of the Diffie-Hellman (DH) group of the initiator must be higher than or equal to that of the responder.

The end without the PFS feature performs SA negotiation according to the PFS requirements of the peer end.

The DH groups 19 and 20 are available only for IKEv2.

9.      (Optional.) Enable the Extended Sequence Number (ESN) feature.

esn enable [ both ]

By default, the ESN feature is disabled.

 

Configuring a manual IPsec policy

In a manual IPsec policy, the parameters are configured manually, such as the keys, the SPIs, and the IP addresses of the two ends in tunnel mode.

Configuration restrictions and guidelines

Make sure the IPsec configuration at the two ends of an IPsec tunnel meets the following requirements:

·           The IPsec policies at the two ends must have IPsec transform sets that use the same security protocols, security algorithms, and encapsulation mode.

·           The remote IPv4 address configured on the local end must be the same as the primary IPv4 address of the interface applied with the IPsec policy at the remote end. The remote IPv6 address configured on the local end must be the same as the first IPv6 address of the interface applied with the IPsec policy at the remote end.

·           At each end, configure parameters for both the inbound SA and the outbound SA, and make sure the SAs in each direction are unique: For an outbound SA, make sure its triplet (remote IP address, security protocol, and SPI) is unique. For an inbound SA, make sure its SPI is unique.

·           The local inbound SA must use the same SPI and keys as the remote outbound SA. The same is true of the local outbound SA and remote inbound SA.

·           The keys for the local and remote inbound and outbound SAs must be in the same format. For example, if the local inbound SA uses a key in characters, the local outbound SA and remote inbound and outbound SAs must use keys in characters.

Configuration procedure

To configure a manual IPsec policy:

 

Step

Command

Remarks

1.      Enter system view.

system-view

N/A

2.      Create a manual IPsec policy entry and enter its view.

ipsec { ipv6-policy | policy } policy-name seq-number manual

By default, no IPsec policy exists.

3.      (Optional.) Configure a description for the IPsec policy.

description text

By default, no description is configured.

4.      Specify an ACL for the IPsec policy.

security acl [ ipv6 ] { acl-number | name acl-name }

By default, an IPsec policy references no ACL.

An IPsec policy can reference only one ACL.

5.      Specify an IPsec transform set for the IPsec policy.

transform-set transform-set-name

By default, an IPsec policy references no IPsec transform set.

A manual IPsec policy can reference only one IPsec transform set.

6.      Specify the remote IP address of the IPsec tunnel.

remote-address { ipv4-address | ipv6 ipv6-address }

By default, the remote IP address of the IPsec tunnel is not specified.

The local IPv4 address of the IPsec tunnel is the primary IPv4 address of the interface to which the IPsec policy is applied. The local IPv6 address of the IPsec tunnel is the first IPv6 address of the interface to which the IPsec policy is applied.

7.      Configure an SPI for the inbound or outbound IPsec SA.

·          To configure an SPI for the inbound IPsec SA:
sa spi inbound { ah | esp } spi-number

·          To configure an SPI for the outbound IPsec SA:
sa spi outbound { ah | esp } spi-number

By default, no SPI is configured for the inbound or outbound IPsec SA.

8.      Configure keys for the IPsec SA.

·          Configure an authentication key in hexadecimal format for AH:
sa hex-key authentication { inbound | outbound } ah { cipher | simple } key-value

·          Configure an authentication key in character format for AH:
sa string-key { inbound | outbound } ah { cipher | simple } key-value

·          Configure a key in character format for ESP:
sa string-key { inbound | outbound } esp { cipher | simple } key-value

·          Configure an authentication key in hexadecimal format for ESP:
sa hex-key authentication { inbound | outbound } esp { cipher | simple } key-value

·          Configure an encryption key in hexadecimal format for ESP:
sa hex-key encryption { inbound | outbound } esp { cipher | simple } key-value

By default, no keys are configured for the IPsec SA.

Configure keys correctly for the security protocol (AH, ESP, or both) you have specified in the IPsec transform set referenced by the IPsec policy.

If you configure a key in both the character and the hexadecimal formats, only the most recent configuration takes effect.

If you configure a key in character format for ESP, the device automatically generates an authentication key and an encryption key for ESP.

 

Configuring an IKE-based IPsec policy

In an IKE-based IPsec policy, the parameters are automatically negotiated through IKE.

To configure an IKE-based IPsec policy, use one of the following methods:

·           Directly configure it by configuring the parameters in IPsec policy view.

·           Configure it by referencing an existing IPsec policy template with the parameters to be negotiated configured.

A device referencing an IPsec policy that is configured in this way cannot initiate an SA negotiation, but it can respond to a negotiation request. The parameters not defined in the template are determined by the initiator. When the remote end's information (such as the IP address) is unknown, this method allows the remote end to initiate negotiations with the local end.

Configuration restrictions and guidelines

Make sure the IPsec configuration at the two ends of an IPsec tunnel meets the following requirements:

·           The IPsec policies at the two tunnel ends must have IPsec transform sets that use the same security protocols, security algorithms, and encapsulation mode.

·           The IPsec policies at the two tunnel ends must have the same IKE profile parameters.

·           An IKE-based IPsec policy can reference up to six IPsec transform sets. During an IKE negotiation, IKE searches for a fully matched IPsec transform set at the two ends of the IPsec tunnel. If no match is found, no SA can be set up, and the packets expecting to be protected will be dropped.

·           The remote IP address of the IPsec tunnel is required on an IKE negotiation initiator and is optional on the responder. The remote IP address specified on the local end must be the same as the local IP address specified on the remote end.

For an IPsec SA established through IKE negotiation:

·           The IPsec SA uses the local lifetime settings or those proposed by the peer, whichever are smaller.

·           The IPsec SA can have both a time-based lifetime and a traffic-based lifetime. The IPsec SA expires when either lifetime expires.

Directly configuring an IKE-based IPsec policy

Step

Command

Remarks

1.      Enter system view.

system-view

N/A

2.      Create an IKE-based IPsec policy entry and enter its view.

ipsec { ipv6-policy | policy } policy-name seq-number isakmp

By default, no IPsec policy exists.

3.      (Optional.) Configure a description for the IPsec policy.

description text

By default, no description is configured.

4.      Specify an ACL for the IPsec policy.

security acl [ ipv6 ] { acl-number | name acl-name } [ aggregation | per-host ]

By default, no ACL is specified for the IPsec policy.

An IPsec policy can reference only one ACL.

5.      Specify IPsec transform sets for the IPsec policy.

transform-set transform-set-name&<1-6>

By default, the IPsec policy references no IPsec transform set.

6.      Specify an IKE profile for the IPsec policy.

ike-profile profile-name

By default, the IPsec policy references no IKE profile, and the device selects an IKE profile configured in system view for negotiation. If no IKE profile is configured, the globally configured IKE settings are used.

An IPsec policy can reference only one IKE profile, and it cannot reference any IKE profile that is already referenced by another IPsec policy or IPsec policy template.

For more information about IKE profiles, see "Configuring IKE."

7.      Specify an IKEv2 profile for the IPsec policy.

ikev2-profile profile-name

By default, no IKEv2 profile is specified for the IPsec policy.

You can specify only one IKEv2 profile for an IPsec policy.

For more information about IKEv2 profiles, see "Configuring IKEv2."

8.      Specify the local IP address of the IPsec tunnel.

local-address { ipv4-address | ipv6 ipv6-address }

By default, the local IPv4 address of IPsec tunnel is the primary IPv4 address of the interface to which the IPsec policy is applied, and the local IPv6 address of the IPsec tunnel is the first IPv6 address of the interface to which the IPsec policy is applied.

The local IP address specified by this command must be the same as the IP address used as the local IKE identity.

9.      Specify the remote IP address of the IPsec tunnel.

remote-address { [ ipv6 ] host-name | ipv4-address | ipv6 ipv6-address }

By default, the remote IP address of the IPsec tunnel is not specified.

10.   Set the IPsec SA lifetime.

sa duration { time-based seconds | traffic-based kilobytes }

By default, the global SA lifetime is used.

11.   (Optional.) Set the IPsec SA idle timeout.

sa idle-time seconds

By default, the global SA idle timeout is used.

12.   (Optional.) Enable the Traffic Flow Confidentiality (TFC) padding feature.

tfc enable

By default, the TFC padding feature is disabled.

13.   Return to system view.

quit

N/A

14.   Set the global SA lifetime.

ipsec sa global-duration { time-based seconds | traffic-based kilobytes }

By default, the time-based SA lifetime is 3600 seconds, and the traffic-based SA lifetime is 1843200 kilobytes.

15.   (Optional.) Enable the global IPsec SA idle timeout feature, and set the global SA idle timeout.

ipsec sa idle-time seconds

By default, the global IPsec SA idle timeout feature is disabled.

 

Configuring an IKE-based IPsec policy by using an IPsec policy template

The configurable parameters for an IPsec policy template are the same as those when you directly configure an IKE-based IPsec policy. The difference is that more parameters are optional for an IPsec policy template. Except the IPsec transform sets and the IKE profile, all other parameters are optional.

A device referencing an IPsec policy that is configured by using an IPsec policy template cannot initiate an SA negotiation, but it can respond to a negotiation request. The parameters not defined in the template are determined by the initiator. For example, in an IPsec policy template, the ACL is optional. If you do not specify an ACL, the IPsec protection range has no limit. So the device accepts all ACL settings of the negotiation initiator. When the remote end's information (such as the IP address) is unknown, the IPsec policy configured by using this method allows the remote end to initiate negotiations with the local end.

To configure an IKE-based IPsec policy by referencing an IPsec policy template:

 

Step

Command

Remarks

1.      Enter system view.

system-view

N/A

2.      Create an IPsec policy template and enter its view.

ipsec { ipv6-policy-template | policy-template } template-name seq-number

By default, no IPsec policy template exists.

3.      (Optional.) Configure a description for the IPsec policy template.

description text

By default, no description is configured.

4.      (Optional.) Specify an ACL for the IPsec policy template.

security acl [ ipv6 ] { acl-number | name acl-name } [ aggregation | per-host ]

By default, no ACL is specified for the IPsec policy template.

An IPsec policy template can reference only one ACL.

5.      Specify the IPsec transform sets for the IPsec policy template to reference.

transform-set transform-set-name&<1-6>

By default, the IPsec policy template references no IPsec transform set.

6.      Specify the IKE profile for the IPsec policy template to reference.

ike-profile profile-name

By default, the IPsec policy template references no IKE profile.

An IPsec policy template can reference only one IKE profile and it cannot reference any IKE profile that is already referenced by another IPsec policy template or IPsec policy.

For more information about IKE profiles, see "Configuring IKE."

7.      Specify an IKEv2 profile for the IPsec policy template.

ikev2-profile profile-name

By default, no IKEv2 profile is specified for the IPsec policy template.

You can specify only one IKEv2 profile for an IPsec policy template.

For more information about IKEv2 profiles, see "Configuring IKEv2."

8.      (Optional.) Specify the local IP address of the IPsec tunnel.

local-address { ipv4-address | ipv6 ipv6-address }

By default, the local IPv4 address of IPsec tunnel is the primary IPv4 address of the interface to which the IPsec policy is applied, and the local IPv6 address of the IPsec tunnel is the first IPv6 address of the interface to which the IPsec policy is applied.

The local IP address specified by this command must be the same as the IP address used as the local IKE identity.

9.      (Optional.) Specify the remote IP address of the IPsec tunnel.

remote-address { [ ipv6 ] host-name | ipv4-address | ipv6 ipv6-address }

By default, the remote IP address of the IPsec tunnel is not specified.

10.   Configure the IPsec SA lifetime.

sa duration { time-based seconds | traffic-based kilobytes }

By default, the global SA lifetime settings are used.

11.   (Optional.) Set the IPsec SA idle timeout.

sa idle-time seconds

By default, the global SA idle timeout is used.

12.   (Optional.) Enable the Traffic Flow Confidentiality (TFC) padding feature.

tfc enable

By default, the TFC padding feature is disabled.

13.   Return to system view.

quit

N/A

14.   Configure the global SA lifetime.

ipsec sa global-duration { time-based seconds | traffic-based kilobytes }

By default, time-based SA lifetime is 3600 seconds, and traffic-based SA lifetime is 1843200 kilobytes.

15.   (Optional.) Enable the global IPsec SA idle timeout feature, and set the global SA idle timeout.

ipsec sa idle-time seconds

By default, the global IPsec SA idle timeout feature is disabled.

16.   Create an IPsec policy by referencing the IPsec policy template.

ipsec { ipv6-policy | policy } policy-name seq-number isakmp template template-name

By default, no IPsec policy exists.

 

Applying an IPsec policy to an interface

You can apply an IPsec policy to an interface to protect certain data flows. To cancel the IPsec protection, remove the application of the IPsec policy.

For each packet to be sent out of an interface applied with an IPsec policy, the interface looks through the IPsec policy entries in the IPsec policy in ascending order of sequence numbers. If the packet matches the ACL of an IPsec policy entry, the interface uses the IPsec policy entry to protect the packet. If no match is found, the interface sends the packet out without IPsec protection.

When the interface receives an IPsec packet whose destination address is the IP address of the local device, it searches for the inbound IPsec SA according to the SPI carried in the IPsec packet header for de-encapsulation. If the de-encapsulated packet matches the permit rule of the ACL, the device processes the packet. Otherwise, it drops the packet.

An interface can reference only one IPsec policy. An IKE-based IPsec policy can be applied to more than one interface, but a manual IPsec policy can be applied to only one interface.

To apply an IPsec policy to an interface:

 

Step

Command

Remarks

1.      Enter system view.

system-view

N/A

2.      Enter interface view.

interface interface-type interface-number

N/A

3.      Apply an IPsec policy to the interface.

ipsec apply { policy | ipv6-policy } policy-name

By default, no IPsec policy is applied to the interface.

An interface can reference only one IPsec policy.

An IKE-mode IPsec policy can be applied to multiple interfaces, and a manual IPsec policy can be applied to only one interface.

 

Enabling ACL checking for de-encapsulated packets

This feature uses the ACL in the IPsec policy to match the IP packets that are de-encapsulated from incoming IPsec packets in tunnel mode, and it discards the IP packets that fail to match the ACL to avoid attacks using forged packets.

To enable ACL checking for de-encapsulated packets:

 

Step

Command

Remarks

1.      Enter system view.

system-view

N/A

2.      Enable ACL checking for de-encapsulated packets.

ipsec decrypt-check enable

By default, this feature is enabled.

 

Configuring IPsec anti-replay

The IPsec anti-replay feature protects networks against anti-replay attacks by using a sliding window mechanism called anti-replay window. This feature checks the sequence number of each received IPsec packet against the current IPsec packet sequence number range of the sliding window. If the sequence number is not in the current sequence number range, the packet is considered a replayed packet and is discarded.

IPsec packet de-encapsulation involves complicated calculation. De-encapsulation of replayed packets is not required, and the de-encapsulation process consumes large amounts of resources and degrades performance, resulting in DoS. IPsec anti-replay can check and discard replayed packets before de-encapsulation.

In some situations, service data packets are received in a different order than their original order. The IPsec anti-replay feature drops them as replayed packets, which impacts communications. If this happens, disable IPsec anti-replay checking or adjust the size of the anti-replay window as required.

IPsec anti-replay does not affect manually created IPsec SAs. According to the IPsec protocol, only IKE-based IPsec SAs support anti-replay checking.

 

IMPORTANT

IMPORTANT:

·       IPsec anti-replay is enabled by default. Failure to detect anti-replay attacks might result in denial of services. Use caution when you disable IPsec anti-replay.

·       Specify an anti-replay window size that is as small as possible to reduce the impact on system performance.

 

To configure IPsec anti-replay:

 

Step

Command

Remarks

1.      Enter system view.

system-view

N/A

2.      Enable IPsec anti-replay.

ipsec anti-replay check

By default, IPsec anti-replay is enabled.

3.      Set the size of the IPsec anti-replay window.

ipsec anti-replay window width

The default size is 64.

 

Configuring IPsec anti-replay redundancy

This feature synchronizes the following information from the master device to all subordinate devices in an IRF fabric at configurable packet-based intervals:

·           Lower bound values of the IPsec anti-replay window for inbound packets.

·           IPsec anti-replay sequence numbers for outbound packets.

This feature, used together with IPsec redundancy, ensures uninterrupted IPsec traffic forwarding and anti-replay protection when the master device in an IRF fabric fails.

To configure IPsec anti-replay redundancy:

 

Step

Command

Remarks

1.      Enter system view.

system-view

N/A

2.      Enable IPsec redundancy.

ipsec redundancy enable

By default, IPsec redundancy is disabled.

3.      Enter IPsec policy view or IPsec policy template view.

·          Enter IPsec policy view:
ipsec
{ policy | ipv6-policy } policy-name seq-number [ isakmp | manual ]

·          Enter IPsec policy template view:
ipsec { policy-template | ipv6-policy-template } template-name seq-number

N/A

4.      Set the anti-replay window synchronization interval for inbound packets and the sequence number synchronization interval for outbound packets.

redundancy replay-interval inbound inbound-interval outbound outbound-interval

By default, the master device synchronizes the anti-replay window every time it receives 1000 packets and the sequence number every time it sends 100000 packets.

 

Binding a source interface to an IPsec policy

For high availability, a core device is usually connected to an ISP through two links, which operate in backup or load sharing mode. The two interfaces negotiate with their peers to establish IPsec SAs respectively. When one interface fails and a link failover occurs, the other interface needs to take some time to renegotiate SAs, resulting in service interruption.

To solve these problems, bind a source interface to an IPsec policy and apply the policy to both interfaces. This enables the two physical interfaces to use the same source interface to negotiate IPsec SAs. As long as the source interface is up, the negotiated IPsec SAs will not be removed and will keep working, regardless of link failover.

Follow these guidelines when you perform this task:

·           Only the IKE-based IPsec policies can be bound to a source interface.

·           An IPsec policy can be bound to only one source interface.

·           A source interface can be bound to multiple IPsec policies.

·           If the source interface bound to an IPsec policy is removed, the IPsec policy becomes a common IPsec policy.

·           If no local address is specified for an IPsec policy that has been bound to a source interface, the IPsec policy uses the IP address of the bound source interface to perform IKE negotiation. If a local address is specified, the IPsec policy uses the local address to perform IKE negotiation.

To bind a source interface to an IPsec policy:

 

Step

Command

Remarks

1.      Enter system view.

system-view

N/A

2.      Bind a source interface to an IPsec policy.

ipsec { ipv6-policy | policy } policy-name local-address interface-type interface-number

By default, no source interface is bound to an IPsec policy.

 

Enabling QoS pre-classify

CAUTION

CAUTION:

If you configure both IPsec and QoS on an interface, make sure the IPsec traffic classification rules match the QoS traffic classification rules. If the rules do not match, QoS might classify the packets of one IPsec SA to different queues, causing packets to be sent out of order. When IPsec anti-replay is enabled, IPsec will drop the incoming packets that are out of the anti-replay window, resulting in packet loss.

 

If you apply both an IPsec policy and a QoS policy to an interface, QoS classifies packets by using the new headers added by IPsec. If you want QoS to classify packets by using the headers of the original IP packets, enable the QoS pre-classify feature.

IPsec traffic classification rules are determined by the referenced ACL rules. For information about QoS policy and QoS traffic classification rules, see ACL and QoS Configuration Guide.

To enable the QoS pre-classify feature:

 

Step

Command

Remarks

1.      Enter system view.

system-view

N/A

2.      Enter IPsec policy view or IPsec policy template view.

·          To enter IPsec policy view:
ipsec { policy | ipv6-policy } policy-name seq-number [ isakmp | manual ]

·          To enter IPsec policy template view:
ipsec { policy-template | ipv6-policy-template } template-name seq-number

N/A

3.      Enable QoS pre-classify.

qos pre-classify

By default, QoS pre-classify is disabled.

 

Enabling logging of IPsec packets

Perform this task to enable the logging of IPsec packets that are discarded because of reasons such as IPsec SA lookup failure, AH-ESP authentication failure, and ESP encryption failure. The log information includes the source and destination IP addresses, the SPI value, and the sequence number of a discarded IPsec packet, and the reason for the failure.

To enable the logging of IPsec packets:

 

Step

Command

Remarks

1.      Enter system view.

system-view

N/A

2.      Enable the logging of IPsec packets.

ipsec logging packet enable

By default, the logging of IPsec packets is disabled.

 

Configuring the DF bit of IPsec packets

Perform this task to configure the Don't Fragment (DF) bit in the new IP header of IPsec packets in one of the following ways:

·           clear—Clears the DF bit in the new header.

·           set—Sets the DF bit in the new header.

·           copy—Copies the DF bit in the original IP header to the new IP header.

You can configure the DF bit in system view and interface view. The interface-view DF bit setting takes precedence over the system-view DF bit setting. If the interface-view DF bit setting is not configured, the interface uses the system-view DF bit setting.

Follow these guidelines when you configure the DF bit:

·           The DF bit setting takes effect only in tunnel mode, and it changes the DF bit in the new IP header rather than the original IP header.

·           Configure the same DF bit setting on the interfaces where the same IPsec policy bound to a source interface has been applied.

To configure the DF bit of IPsec packets on an interface:

 

Step

Command

Remarks

1.      Enter system view.

system-view

N/A

2.      Enter interface view.

interface interface-type interface-number

N/A

3.      Configure the DF bit of IPsec packets on the interface.

ipsec df-bit { clear | copy | set }

By default, the interface uses the global DF bit setting.

 

To configure the DF bit of IPsec packets globally:

 

Step

Command

Remarks

1.      Enter system view.

system-view

N/A

2.      Configure the DF bit of IPsec packets globally.

ipsec global-df-bit { clear | copy | set }

By default, IPsec copies the DF bit in the original IP header to the new IP header.

 

Configuring IPsec for IPv6 routing protocols

Configuration task list

Complete the following tasks to configure IPsec for IPv6 routing protocols:

 

Tasks at a glance

(Required.) Configuring an IPsec transform set

(Required.) Configuring a manual IPsec profile

(Required.) Applying the IPsec profile to an IPv6 routing protocol (see Layer 3IP Routing Configuration Guide)

(Optional.) Enabling logging of IPsec packets

(Optional.) Configuring SNMP notifications for IPsec

 

Configuring a manual IPsec profile

An IPsec profile is similar to an IPsec policy. The difference is that an IPsec profile is uniquely identified by a name and it does not support ACL configuration. An IPsec profile defines the IPsec transform set used for protecting data flows, and specifies SPIs and the keys used by the SAs.

The IPsec profile configurations at the two tunnel ends must meet the following requirements:

·           The IPsec transform set referenced by the IPsec profile at the two tunnel ends must have the same security protocol, encryption and authentication algorithms, and packet encapsulation mode.

·           The local inbound and outbound IPsec SAs must have the same SPI and key.

¡  The IPsec SAs on the devices in the same scope must have the same key. The scope is defined by protocols. For OSPF, the scope consists of OSPF neighbors or an OSPF area. For RIPng, the scope consists of directly-connected neighbors or a RIPng process. For BGP, the scope consists of BGP peers or a BGP peer group.

·           The keys for the IPsec SAs at the two tunnel ends must be configured in the same format. For example, if the key at one end is entered as a string of characters, the key on the other end must also be entered as a string of characters.

To configure a manual IPsec profile:

 

Step

Command

Remarks

1.      Enter system view.

system-view

N/A

2.      Create a manual IPsec profile and enter its view.

ipsec profile profile-name manual

By default, no IPsec profile exists.

The manual keyword is not needed if you enter the view of an existing IPsec profile.

3.      (Optional.) Configure a description for the IPsec profile.

description text

By default, no description is configured.

4.      Reference an IPsec transform set for the IPsec profile.

transform-set transform-set-name

By default, no IPsec transform set is referenced for an IPsec profile.

The referenced IPsec transform set must use the transport mode.

5.      Configure an SPI for an SA.

sa spi { inbound | outbound } { ah | esp } spi-number

By default, no SPI is configured for an SA.

6.      Configure keys for the IPsec SA.

·          Configure an authentication key in hexadecimal format for AH:
sa hex-key authentication { inbound | outbound } ah { cipher | simple } key-value

·          Configure an authentication key in character format for AH:
sa string-key { inbound | outbound } ah { cipher | simple } key-value

·          Configure a key in character format for ESP:
sa string-key { inbound | outbound } esp [ cipher | simple ] key-value

·          Configure an authentication key in hexadecimal format for ESP:
sa hex-key authentication  { inbound | outbound } esp { cipher | simple } key-value

·          Configure an encryption key in hexadecimal format for ESP:
sa hex-key encryption { inbound | outbound } esp { cipher | simple } key-value

By default, no keys are configured for the IPsec SA.

Configure a key for the security protocol (AH, ESP, or both) you have specified.

If you configure a key in character format for ESP, the device automatically generates an authentication key and an encryption key for ESP.

If you configure a key in both the character and hexadecimal formats, only the most recent configuration takes effect.

 

Configuring SNMP notifications for IPsec

After you enable SNMP notifications for IPsec, the IPsec module notifies the NMS of important module events. The notifications are sent to the device's SNMP module. You can configure the notification transmission parameters for the SNMP module to specify how the SNMP module displays notifications. For more information about SNMP notifications, see Network Management and Monitoring Configuration Guide.

To generate and output SNMP notifications for a specific IPsec failure or event type, perform the following tasks:

1.      Enable SNMP notifications for IPsec globally.

2.      Enable SNMP notifications for the failure or event type.

To configure SNMP notifications for IPsec:

 

Step

Command

Remarks

1.      Enter system view

system-view

N/A

2.      Enable SNMP notifications for IPsec globally.

snmp-agent trap enable ipsec global

By default, SNMP notifications for IPsec are disabled.

3.      Enable SNMP notifications for the specified failure or event types.

snmp-agent trap enable ipsec [ auth-failure | decrypt-failure | encrypt-failure | invalid-sa-failure | no-sa-failure | policy-add | policy-attach | policy-delete | policy-detach | tunnel-start | tunnel-stop ] *

By default, SNMP notifications for all failure and event types are disabled.

 

Displaying and maintaining IPsec

Execute display commands in any view and reset commands in user view.

 

Task

Command

Display IPsec policy information.

display ipsec { ipv6-policy | policy } [ policy-name [ seq-number ] ]

Display IPsec policy template information.

display ipsec { ipv6-policy-template | policy-template } [ template-name [ seq-number ] ]

Display IPsec profile information.

display ipsec profile [ profile-name ]

Display IPsec transform set information.

display ipsec transform-set [ transform-set-name ]

Display IPsec SA information.

display ipsec sa [ brief | count | interface interface-type interface-number | { ipv6-policy | policy } policy-name [ seq-number ] | profile policy-name | remote [ ipv6 ] ip-address ]

Display IPsec statistics.

display ipsec statistics [ tunnel-id tunnel-id ]

Display IPsec tunnel information.

display ipsec tunnel { brief | count | tunnel-id tunnel-id }

Clear IPsec SAs.

reset ipsec sa [ { ipv6-policy | policy } policy-name [ seq-number ] | profile policy-name | remote { ipv4-address | ipv6 ipv6-address } | spi { ipv4-address | ipv6 ipv6-address } { ah | esp } spi-num ]

Clear IPsec statistics.

reset ipsec statistics [ tunnel-id tunnel-id ]

 

IPsec configuration examples

Configuring a manual mode IPsec tunnel for IPv4 packets

Network requirements

As shown in Figure 4, establish an IPsec tunnel between Switch A and Switch B to protect data flows between the switches. Configure the tunnel as follows:

·           Specify the encapsulation mode as tunnel, the security protocol as ESP, the encryption algorithm as AES-CBC-192, and the authentication algorithm as HMAC-SHA1.

·           Manually set up IPsec SAs.

Figure 4 Network diagram

 

Configuration procedure

1.      Configure Switch A:

# Configure an IP address for VLAN-interface 1.

<SwitchA> system-view

[SwitchA] interface vlan-interface 1

[SwitchA-Vlan-interface1] ip address 2.2.2.1 255.255.255.0

[SwitchA-Vlan-interface1] quit

# Configure an ACL to identify data flows between Switch A and Switch B.

[SwitchA] acl number 3101

[SwitchA-acl-adv-3101] rule 0 permit ip source 2.2.2.1 0 destination 2.2.3.1 0

[SwitchA-acl-adv-3101] quit

# Create an IPsec transform set named tran1.

[SwitchA] ipsec transform-set tran1

# Specify the encapsulation mode as tunnel.

[SwitchA-ipsec-transform-set-tran1] encapsulation-mode tunnel

# Specify the security protocol as ESP.

[SwitchA-ipsec-transform-set-tran1] protocol esp

# Specify the ESP encryption and authentication algorithms.

[SwitchA-ipsec-transform-set-tran1] esp encryption-algorithm aes-cbc-192

[SwitchA-ipsec-transform-set-tran1] esp authentication-algorithm sha1

[SwitchA-ipsec-transform-set-tran1] quit

# Create a manual IPsec policy entry. Specify the policy name as map1 and set the sequence number to 10.

[SwitchA] ipsec policy map1 10 manual

# Apply ACL 3101.

[SwitchA-ipsec-policy-manual-map1-10] security acl 3101

# Apply the IPsec transform set tran1.

[SwitchA-ipsec-policy-manual-map1-10] transform-set tran1

# Specify the remote IP address of the IPsec tunnel as 2.2.3.1.

[SwitchA-ipsec-policy-manual-map1-10] remote-address 2.2.3.1

# Configure inbound and outbound SPIs for ESP.

[SwitchA-ipsec-policy-manual-map1-10] sa spi outbound esp 12345

[SwitchA-ipsec-policy-manual-map1-10] sa spi inbound esp 54321

# Configure the inbound and outbound SA keys for ESP.

[SwitchA-ipsec-policy-manual-map1-10] sa string-key outbound esp simple abcdefg

[SwitchA-ipsec-policy-manual-map1-10] sa string-key inbound esp simple gfedcba

[SwitchA-ipsec-policy-manual-map1-10] quit

# Apply the IPsec policy map1 to interface VLAN-interface 1.

[SwitchA] interface vlan-interface 1

[SwitchA-Vlan-interface1] ipsec apply policy map1

2.      Configure Switch B:

# Configure an IP address for VLAN-interface 1.

<SwitchB> system-view

[SwitchB] interface vlan-interface 1

[SwitchB-Vlan-interface1] ip address 2.2.3.1 255.255.255.0

[SwitchB-Vlan-interface1] quit

# Configure an ACL to identify data flows between Switch B and Switch A.

[SwitchB] acl number 3101

[SwitchB-acl-adv-3101] rule 0 permit ip source 2.2.3.1 0 destination 2.2.2.1 0

[SwitchB-acl-adv-3101] quit

# Create an IPsec transform set named tran1.

[SwitchB] ipsec transform-set tran1

# Specify the encapsulation mode as tunnel.

[SwitchB-ipsec-transform-set-tran1] encapsulation-mode tunnel

# Specify the security protocol as ESP.

[SwitchB-ipsec-transform-set-tran1] protocol esp

# Specify the ESP encryption and authentication algorithms.

[SwitchB-ipsec-transform-set-tran1] esp encryption-algorithm aes-cbc-192

[SwitchB-ipsec-transform-set-tran1] esp authentication-algorithm sha1

[SwitchB-ipsec-transform-set-tran1] quit

# Create a manual IPsec policy entry. Specify the policy name as use1 and set the sequence number to 10.

[SwitchB] ipsec policy use1 10 manual

# Apply ACL 3101.

[SwitchB-ipsec-policy-manual-use1-10] security acl 3101

# Apply IPsec transform set tran1.

[SwitchB-ipsec-policy-manual-use1-10] transform-set tran1

# Specify the remote IP address of the IPsec tunnel as 2.2.2.1.

[SwitchB-ipsec-policy-manual-use1-10] remote-address 2.2.2.1

# Configure the inbound and outbound SPIs for ESP.

[SwitchB-ipsec-policy-manual-use1-10] sa spi outbound esp 54321

[SwitchB-ipsec-policy-manual-use1-10] sa spi inbound esp 12345

# Configure the inbound and outbound SA keys for ESP.

[SwitchB-ipsec-policy-manual-use1-10] sa string-key outbound esp simple gfedcba

[SwitchB-ipsec-policy-manual-use1-10] sa string-key inbound esp simple abcdefg

[SwitchB-ipsec-policy-manual-use1-10] quit

# Apply the IPsec policy use1 to interface VLAN-interface 1.

[SwitchB] interface vlan-interface 1

[SwitchB-Vlan-interface1] ipsec apply policy use1

Verifying the configuration

After the configuration is completed, an IPsec tunnel between Switch A and Switch B is established, and the traffic between the switches is IPsec protected. This example uses Switch A to verify the configuration.

# Use the display ipsec sa command to display IPsec SAs on Switch A.

[SwitchA] display ipsec sa

-------------------------------

Interface: Vlan-interface 1

-------------------------------

 

  -----------------------------

  IPsec policy: map1

  Sequence number: 10

  Mode: manual

  -----------------------------

    Tunnel id: 549

    Encapsulation mode: tunnel

    Path MTU: 1443

    Tunnel:

        local  address: 2.2.2.1

        remote address: 2.2.3.1

    Flow:

        as defined in ACL 3101

    [Inbound ESP SA]

      SPI: 54321 (0x0000d431)

      Transform set: ESP-ENCRYPT-AES-CBC-192 ESP-AUTH-SHA1

      No duration limit for this SA

    [Outbound ESP SA]

      SPI: 12345 (0x00003039)

      Transform set: ESP-ENCRYPT-AES-CBC-192 ESP-AUTH-SHA1

      No duration limit for this SA

Configuring an IKE-based IPsec tunnel for IPv4 packets

Network requirements

As shown in Figure 5, establish an IPsec tunnel between Switch A and Switch B to protect data flows between the switches. Configure the IPsec tunnel as follows:

·           Specify the encapsulation mode as tunnel, the security protocol as ESP, the encryption algorithm as AES-CBC-192, and the authentication algorithm as HMAC-SHA1.

·           Set up SAs through IKE negotiation.

Figure 5 Network diagram

 

Configuration procedure

1.      Configure Switch A:

# Configure an IP address for VLAN-interface 1.

<SwitchA> system-view

[SwitchA] interface vlan-interface 1

[SwitchA-Vlan-interface1] ip address 2.2.2.1 255.255.255.0

[SwitchA-Vlan-interface1] quit

# Configure an ACL to identify data flows between Switch A and Switch B.

[SwitchA] acl number 3101

[SwitchA-acl-adv-3101] rule 0 permit ip source 2.2.2.1 0 destination 2.2.3.1 0

[SwitchA-acl-adv-3101] quit

# Create an IPsec transform set named tran1.

[SwitchA] ipsec transform-set tran1

# Specify the encapsulation mode as tunnel.

[SwitchA-ipsec-transform-set-tran1] encapsulation-mode tunnel

# Specify the security protocol as ESP.

[SwitchA-ipsec-transform-set-tran1] protocol esp

# Specify the ESP encryption and authentication algorithms.

[SwitchA-ipsec-transform-set-tran1] esp encryption-algorithm aes-cbc-192

[SwitchA-ipsec-transform-set-tran1] esp authentication-algorithm sha1

[SwitchA-ipsec-transform-set-tran1] quit

# Create the IKE keychain named keychain1.

[SwitchA] ike keychain keychain1

# Specify 12345zxcvb!@#$%ZXCVB in plain text as the pre-shared key to be used with the peer 2.2.3.1.

[SwitchA-ike-keychain-keychain1] pre-shared-key address 2.2.3.1 255.255.255.0 key simple 12345zxcvb!@#$%ZXCVB

[SwitchA-ike-keychain-keychain1] quit

# Create the IKE profile named profile1.

[SwitchA] ike profile profile1

# Reference the keychain keychain1.

[SwitchA-ike-profile-profile1] keychain keychain1

[SwitchA-ike-profile-profile1] match remote identity address 2.2.3.1 255.255.255.0

[SwitchA-ike-profile-profile1] quit

# Create an IKE-based IPsec policy entry. Specify the policy name as map1 and set the sequence number to 10.

[SwitchA] ipsec policy map1 10 isakmp

# Apply ACL 3101.

[SwitchA-ipsec-policy-isakmp-map1-10] security acl 3101

# Apply the IPsec transform set tran1.

[SwitchA-ipsec-policy-isakmp-map1-10] transform-set tran1

# Specify the local and remote IP addresses of the IPsec tunnel as 2.2.2.1 and 2.2.3.1.

[SwitchA-ipsec-policy-isakmp-map1-10] local-address 2.2.2.1

[SwitchA-ipsec-policy-isakmp map1-10] remote-address 2.2.3.1

# Apply the IKE profile profile1.

[SwitchA-ipsec-policy-isakmp-map1-10] ike-profile profile1

[SwitchA-ipsec-policy-isakmp-map1-10] quit

# Specify slot 1 for forwarding traffic on VLAN-interface 1.

[SwitchA] interface vlan-interface 1

[SwitchA-Vlan-interface1] service slot 1

# Apply the IPsec policy map1 to interface VLAN-interface 1.

[SwitchA-Vlan-interface1] ipsec apply policy map1

2.      Configure Switch B:

# Configure an IP address for VLAN-interface 1.

<SwitchB> system-view

[SwitchB] interface vlan-interface 1

[SwitchB-Vlan-interface1] ip address 2.2.3.1 255.255.255.0

[SwitchB-Vlan-interface1] quit

# Configure an ACL to identify data flows between Switch B and Switch A.

[SwitchB] acl number 3101

[SwitchB-acl-adv-3101] rule 0 permit ip source 2.2.3.1 0 destination 2.2.2.1 0

[SwitchB-acl-adv-3101] quit

# Create an IPsec transform set named tran1.

[SwitchB] ipsec transform-set tran1

# Specify the encapsulation mode as tunnel.

[SwitchB-ipsec-transform-set-tran1] encapsulation-mode tunnel

# Specify the security protocol as ESP.

[SwitchB-ipsec-transform-set-tran1] protocol esp

# Specify the ESP encryption and authentication algorithms.

[SwitchB-ipsec-transform-set-tran1] esp encryption-algorithm aes-cbc-192

[SwitchB-ipsec-transform-set-tran1] esp authentication-algorithm sha1

[SwitchB-ipsec-transform-set-tran1] quit

# Create the IKE keychain named keychain1.

[SwitchB] ike keychain keychain1

# Specify 12345zxcvb!@#$%ZXCVB in plain text as the pre-shared key to be used with the peer 2.2.2.1.

[SwitchB-ike-keychain-keychain1] pre-shared-key address 2.2.2.1 255.255.255.0 key simple 12345zxcvb!@#$%ZXCVB

[SwitchB-ike-keychain-keychain1] quit

# Create the IKE profile named profile1.

[SwitchB] ike profile profile1

# Reference the keychain keychain1.

[SwitchB-ike-profile-profile1] keychain keychain1

[SwitchB-ike-profile-profile1] match remote identity address 2.2.2.1 255.255.255.0

[SwitchB-ike-profile-profile1] quit

# Create an IKE-based IPsec policy entry. Specify the policy name as use1 and set the sequence number to 10.

[SwitchB] ipsec policy use1 10 isakmp

# Apply ACL 3101.

[SwitchB-ipsec-policy-isakmp-use1-10] security acl 3101

# Apply the IPsec transform set tran1.

[SwitchB-ipsec-policy-isakmp-use1-10] transform-set tran1

# Specify the local and remote IP addresses of the IPsec tunnel as 2.2.3.1 and 2.2.2.1.

[SwitchB-ipsec-policy-isakmp-map1-10] local-address 2.2.3.1

[SwitchB-ipsec-policy-isakmp-use1-10] remote-address 2.2.2.1

# Apply the IKE profile profile1.

[SwitchB-ipsec-policy-isakmp-use1-10] ike-profile profile1

[SwitchB-ipsec-policy-isakmp-use1-10] quit

# Specify slot 1 for forwarding traffic on VLAN-interface 1.

[SwitchB] interface vlan-interface 1

[SwitchB-Vlan-interface1] service slot 1

# Apply the IPsec policy use1 to interface VLAN-interface 1.

[SwitchB-Vlan-interface1] ipsec apply policy use1

Verifying the configuration

# Initiate a connection from Switch A to Switch B to trigger the IKE negotiation. After IPsec SAs are successfully negotiated by IKE, the traffic between the two switches is IPsec protected.

Configuring IPsec for RIPng

Network requirements

As shown in Figure 6, Switch A, Switch B, and Switch C learn IPv6 routes through RIPng.

Establish an IPsec tunnel between the switches to protect the RIPng packets transmitted in between. Specify the security protocol as ESP, the encryption algorithm as 128-bit AES, and the authentication algorithm as HMAC-SHA1 for the IPsec tunnel.

Figure 6 Network diagram

 

Requirements analysis

To meet the network requirements, perform the following tasks:

1.      Configure basic RIPng.

For more information about RIPng configurations, see Layer 3—IP Routing Configuration Guide.

2.      Configure an IPsec profile.

¡  The IPsec profiles on all the switches must have IPsec transform sets that use the same security protocol, authentication and encryption algorithms, and encapsulation mode.

¡  The SPI and key configured for the inbound SA and those for the outbound SA must be the same on each switch.

¡  The SPI and key configured for the SAs on all the switches must be the same.

3.      Apply the IPsec profile to a RIPng process or to an interface.

Configuration procedure

1.      Configure Switch A:

# Configure IPv6 addresses for interfaces. (Details not shown.)

# Configure basic RIPng.

<SwitchA> system-view

[SwitchA] ripng 1

[SwitchA-ripng-1] quit

[SwitchA] interface vlan-interface 100

[SwitchA-Vlan-interface100] ripng 1 enable

[SwitchA-Vlan-interface100] quit

# Create and configure the IPsec transform set named tran1.

[SwitchA] ipsec transform-set tran1

[SwitchA-ipsec-transform-set-tran1] encapsulation-mode transport

[SwitchA-ipsec-transform-set-tran1] protocol esp

[SwitchA-ipsec-transform-set-tran1] esp encryption-algorithm aes-cbc-128

[SwitchA-ipsec-transform-set-tran1] esp authentication-algorithm sha1

[SwitchA-ipsec-transform-set-tran1] quit

# Create and configure the IPsec profile named profile001.

[SwitchA] ipsec profile profile001 manual

[SwitchA-ipsec-profile-profile1001] transform-set tran1

[SwitchA-ipsec-profile-profile1001] sa spi outbound esp 123456

[SwitchA-ipsec-profile-profile1001] sa spi inbound esp 123456

[SwitchA-ipsec-profile-profile1001] sa string-key outbound esp simple abcdefg

[SwitchA-ipsec-profile-profile1001] sa string-key inbound esp simple abcdefg

[SwitchA-ipsec-profile-profile1001] quit

# Apply the IPsec profile to RIPng process 1.

[SwitchA] ripng 1

[SwitchA-ripng-1] enable ipsec-profile profile001

[SwitchA-ripng-1] quit

2.      Configure Switch B:

# Configure IPv6 addresses for interfaces. (Details not shown.)

# Configure basic RIPng.

<SwitchB> system-view

[SwitchB] ripng 1

[SwitchB-ripng-1] quit

[SwitchB] interface vlan-interface 200

[SwitchB-Vlan-interface200] ripng 1 enable

[SwitchB-Vlan-interface200] quit

[SwitchB] interface vlan-interface 100

[SwitchB-Vlan-interface100] ripng 1 enable

[SwitchB-Vlan-interface100] quit

# Create and configure the IPsec transform set named tran1.

[SwitchB] ipsec transform-set tran1

[SwitchB-ipsec-transform-set-tran1] encapsulation-mode transport

[SwitchB-ipsec-transform-set-tran1] protocol esp

[SwitchB-ipsec-transform-set-tran1] esp encryption-algorithm aes-cbc-128

[SwitchB-ipsec-transform-set-tran1] esp authentication-algorithm sha1

[SwitchB-ipsec-transform-set-tran1] quit

# Create and configure the IPsec profile named profile001.

[SwitchB] ipsec profile profile001 manual

[SwitchB-ipsec-profile-profile001] transform-set tran1

[SwitchB-ipsec-profile-profile001] sa spi outbound esp 123456

[SwitchB-ipsec-profile-profile001] sa spi inbound esp 123456

[SwitchB-ipsec-profile-profile001] sa string-key outbound esp simple abcdefg

[SwitchB-ipsec-profile-profile001] sa string-key inbound esp simple abcdefg

[SwitchB-ipsec-profile-profile001] quit

# Apply the IPsec profile to RIPng process 1.

[SwitchB] ripng 1

[SwitchB-ripng-1] enable ipsec-profile profile001

[SwitchB-ripng-1] quit

3.      Configure Switch C:

# Configure IPv6 addresses for interfaces. (Details not shown.)

# Configure basic RIPng.

<SwitchC> system-view

[SwitchC] ripng 1

[SwitchC-ripng-1] quit

[SwitchC] interface vlan-interface 200

[SwitchC-Vlan-interface200] ripng 1 enable

[SwitchC-Vlan-interface200] quit

# Create and configure the IPsec transform set named tran1.

[SwitchC] ipsec transform-set tran1

[SwitchC-ipsec-transform-set-tran1] encapsulation-mode transport

[SwitchC-ipsec-transform-set-tran1] protocol esp

[SwitchC-ipsec-transform-set-tran1] esp encryption-algorithm aes-cbc-128

[SwitchC-ipsec-transform-set-tran1] esp authentication-algorithm sha1

[SwitchC-ipsec-transform-set-tran1] quit

# Create and configure the IPsec profile named profile001.

[SwitchC] ipsec profile profile001 manual

[SwitchC-ipsec-profile-profile001] transform-set tran1

[SwitchC-ipsec-profile-profile001] sa spi outbound esp 123456

[SwitchC-ipsec-profile-profile001] sa spi inbound esp 123456

[SwitchC-ipsec-profile-profile001] sa string-key outbound esp simple abcdefg

[SwitchC-ipsec-profile-profile001] sa string-key inbound esp simple abcdefg

[SwitchC-ipsec-profile-profile001] quit

# Apply the IPsec profile to RIPng process 1.

[SwitchC] ripng 1

[SwitchC-ripng-1] enable ipsec-profile profile001

[SwitchC-ripng-1] quit

Verifying the configuration

After the configuration is completed, Switch A, Switch B, and Switch C learn IPv6 routing information through RIPng. IPsec SAs are set up successfully on the switches to protect RIPng packets. This example uses Switch A to verify the configuration.

# Use the display ripng command to display the RIPng configuration. The output shows that the IPsec profile profile001 has been applied to RIPng process 1.

[SwitchA] display ripng 1

    RIPng process : 1

       Preference : 100

       Checkzero : Enabled

       Default Cost : 0

       Maximum number of balanced paths : 8

       Update time   :   30 sec(s)  Timeout time         :  180 sec(s)

       Suppress time :  120 sec(s)  Garbage-Collect time :  120 sec(s)

       Number of periodic updates sent : 186

       Number of trigger updates sent : 1

       IPsec profile name: profile001

 

# Use the display ipsec sa command to display the established IPsec SAs.

[SwitchA] display ipsec sa

-------------------------------

Global IPsec SA

-------------------------------

 

  -----------------------------

  IPsec profile: profile001

  Mode: manual

  -----------------------------

    Encapsulation mode: transport

    [Inbound ESP SA]

      SPI: 123456 (0x3039)

      Transform set: ESP-ENCRYPT-AES-CBC-128 ESP-AUTH-SHA1

      No duration limit for this SA

    [Outbound ESP SA]

      SPI: 123456 (0x3039)

      Transform set: ESP-ENCRYPT-AES-CBC-128 ESP-AUTH-SHA1

      No duration limit for this SA


Configuring IKE

Unless otherwise specified, the term "IKE" in this chapter refers to IKEv1.

Overview

Built on a framework defined by ISAKMP, Internet Key Exchange (IKE) provides automatic key negotiation and SA establishment services for IPsec.

IKE provides the following benefits for IPsec:

·           Automatically negotiates IPsec parameters.

·           Performs DH exchanges to calculate shared keys, making sure each SA has a key that is independent of other keys.

·           Automatically negotiates SAs when the sequence number in the AH or ESP header overflows, making sure IPsec can provide the anti-replay service by using the sequence number.

As shown in Figure 7, IKE negotiates SAs for IPsec and transfers the SAs to IPsec, and IPsec uses the SAs to protect IP packets.

Figure 7 Relationship between IKE and IPsec

 

IKE negotiation process

IKE negotiates keys and SAs for IPsec in two phases:

1.      Phase 1—The two peers establish an IKE SA, a secure, authenticated channel for communication. In this phase, two modes are available: main mode and aggressive mode.

2.      Phase 2—Using the IKE SA established in phase 1, the two peers negotiate to establish IPsec SAs.

Figure 8 IKE exchange process in main mode

 

As shown in Figure 8, the main mode of IKE negotiation in phase 1 involves three pairs of messages:

·           SA exchange—Used for negotiating the IKE security policy.

·           Key exchange—Used for exchanging the DH public value and other values, such as the random number. The two peers use the exchanged data to generate key data and use the encryption key and authentication key to ensure the security of IP packets.

·           ID and authentication data exchange—Used for identity authentication.

The main difference between the main mode and the aggressive mode is that the aggressive mode does not provide identity information protection and exchanges only three messages, rather than three pairs. The main mode provides identity information protection but is slower.

IKE security mechanism

IKE has a series of self-protection mechanisms and supports secure identity authentication, key distribution, and IPsec SA establishment on insecure networks.

Identity authentication

The IKE identity authentication mechanism is used to authenticate the identity of the communicating peers. The device supports the following identity authentication methods:

·           Pre-shared key authentication—Two communicating peers use the pre-configured shared key for identity authentication.

·           RSA signature authentication and DSA signature authentication—Two communicating peers use the digital certificates issued by the CA for identity authentication.

The pre-shared key authentication method does not require certificates and is easy to configure. It is usually deployed in small networks.

The signature authentication methods provide higher security and are usually deployed in networks with the headquarters and some branches. When deployed in a network with many branches, a signature authentication method can simplify the configuration because only one PKI domain is required. If you use the pre-shared key authentication method, you must configure a pre-shared key for each branch on the Headquarters node.

DH algorithm

The DH algorithm is a public key algorithm. With this algorithm, two peers can exchange keying material and then use the material to calculate the shared keys. Due to the decryption complexity, a third party cannot decrypt the keys even after intercepting all keying materials.

PFS

The Perfect Forward Secrecy (PFS) feature is a security feature based on the DH algorithm. After PFS is enabled, an additional DH exchange is performed in IKE phase 2 to make sure IPsec keys have no derivative relations with IKE keys and a broken key brings no threats to other keys.

Protocols and standards

·           RFC 2408, Internet Security Association and Key Management Protocol (ISAKMP)

·           RFC 2409, The Internet Key Exchange (IKE)

·           RFC 2412, The OAKLEY Key Determination Protocol

FIPS compliance

The device supports the FIPS mode that complies with NIST FIPS 140-2 requirements. Support for features, commands, and parameters might differ in FIPS mode (see "Configuring FIPS") and non-FIPS mode.

IKE configuration prerequisites

Determine the following parameters prior to IKE configuration:

·           The algorithms to be used during IKE negotiation, including the identity authentication method, encryption algorithm, authentication algorithm, and DH group.

¡  Different algorithms provide different levels of protection. A stronger algorithm provides more resistance to decryption but uses more resources.

¡  A DH group that uses more bits provides higher security but needs more time for processing.

·           The pre-shared key or PKI domain for IKE negotiation. For more information about PKI, see "Configuring PKI."

·           The IKE-based IPsec policies for the communicating peers. If an IPsec policy does not reference any IKE profile, the device selects an IKE profile for the IPsec policy. If no IKE profile is configured, the globally configured IKE settings are used. For more information about IPsec, see "Configuring an IKE-based IPsec policy."

IKE configuration task list

Tasks at a glance

Remarks

(Optional.) Configuring an IKE profile

N/A

(Optional.) Configuring an IKE proposal

Required when the IKE profile needs to reference IKE proposals.

(Optional.) Configuring an IKE keychain

Required when pre-shared authentication is used in IKE negotiation phase 1.

(Optional.) Configuring the global identity information

N/A

(Optional.) Configuring the IKE keepalive feature

N/A

(Optional.) Configuring the IKE NAT keepalive feature

N/A

(Optional.) Configuring IKE DPD

N/A

(Optional.) Enabling invalid SPI recovery

N/A

(Optional.) Setting the maximum number of IKE SAs

N/A

(Optional.) Configuring SNMP notifications for IKE

N/A

 

Configuring an IKE profile

An IKE profile is intended to provide a set of parameters for IKE negotiation. To configure an IKE profile, you can do the following:

1.      Configure peer IDs. When an end needs to select an IKE profile, it compares the received peer ID with the peer IDs of its local IKE profiles. If a match is found, it uses the IKE profile with the matching peer ID for IKE negotiation.

2.      Configure the IKE keychain or PKI domain for the IKE proposals to use:

¡  To use digital signature authentication, configure a PKI domain.

¡  To use pre-shared key authentication, configure an IKE keychain.

3.      Specify the negotiation mode (main or aggressive) that the device uses as the initiator. When the device acts as the responder, it uses the IKE negotiation mode of the initiator.

4.      Specifies the IKE proposals that the device can use as the initiator. An IKE proposal specified earlier has a higher priority. When the device acts as the responder, it uses the IKE proposals configured in system view to match the IKE proposals received from the initiator. If a match is not found, the negotiation fails.

5.      Configure the local ID, the ID that the device uses to identify itself to the peer during IKE negotiation:

¡  For digital signature authentication, the device can use any type of ID. If the local ID is an IP address that is different from the IP address in the local certificate, the device uses the FQDN (the device name configured by using the sysname command) instead.

¡  For pre-shared key authentication, the device can use any type of ID other than the DN.

6.      Configure the IKE DPD feature to detect dead IKE peers. You can also configure this feature in system view. The IKE DPD settings configured in the IKE profile takes precedence over those configured in system view.

7.      Specify a local interface or IP address for the IKE profile so the profile can be applied only to the specified interface or IP address. For this task, specify the local address configured in IPsec policy or IPsec policy template view (using the local-address command). If no local address is configured, specify the IP address of the interface that references the IPsec policy.

8.      Specify a priority number for the IKE profile. To determine the priority of an IKE profile:

a.    First, the device examines the existence of the match local address command. An IKE profile with the match local address command configured has a higher priority.

b.    If a tie exists, the device compares the priority numbers. An IKE profile with a smaller priority number has a higher priority.

c.    If a tie still exists, the device prefers an IKE profile configured earlier.

To configure an IKE profile:

 

Step

Command

Remarks

1.      Enter system view.

system-view

N/A

2.      Create an IKE profile and enter its view.

ike profile profile-name

By default, no IKE profile is configured.

3.      Configure a peer ID.

match remote { certificate policy-name | identity { address { { ipv4-address [ mask | mask-length ] | range low-ipv4-address high-ipv4-address } | ipv6 { ipv6-address [ prefix-length ] | range low-ipv6-address high-ipv6-address } } [ vpn-instance vpn-name ] | fqdn fqdn-name | user-fqdn user-fqdn-name } }

By default, an IKE profile has no peer ID.

Each of the two peers must have at least one peer ID configured.

4.      Specify the keychain for pre-shared key authentication or the PKI domain used to request a certificate for digital signature authentication.

·          To specify the keychain for pre-shared key authentication:
keychain keychain-name

·          To specify the PKI domain used to request a certificate for digital signature authentication:
certificate domain domain-name

Configure at least one command as required.

By default, no IKE keychain or PKI domain is specified for an IKE profile.

5.      Specify the IKE negotiation mode for phase 1.

·          In non-FIPS mode:
exchange-mode { aggressive | main }

·          In FIPS mode:
exchange-mode main

By default, the main mode is used during IKE negotiation phase 1.

6.      Specify the IKE proposals for the IKE profile to reference.

proposal proposal-number&<1-6>

By default, an IKE profile references no IKE proposals and uses the IKE proposals configured in system view for IKE negotiation.

7.      Configure the local ID.

local-identity { address { ipv4-address | ipv6 ipv6-address } | dn | fqdn [ fqdn-name ] | user-fqdn [ user-fqdn-name ] }

By default, no local ID is configured for an IKE profile, and an IKE profile uses the local ID configured in system view. If the local ID is not configured in system view, the IKE profile uses the IP address of the interface to which the IPsec policy or IPsec policy template is applied as the local ID.

8.       (Optional.) Configure IKE DPD.

dpd interval interval-seconds [ retry seconds ] { on-demand | periodic }

By default, the IKE DPD feature is not configured for an IKE profile and an IKE profile uses the DPD settings configured in system view. If the IKE DPD feature is not configured in system either, the device does not perform dead IKE peer detection.

9.       (Optional.) Specify the local interface or IP address to which the IKE profile can be applied.

match local address { interface-type interface-number | { ipv4-address | ipv6 ipv6-address } [ vpn-instance vpn-name ] }

By default, an IKE profile can be applied to any local interface or IP address.

10.   (Optional.) Specify an inside VPN instance.

inside-vpn vpn-instance vpn-name

By default, no inside VPN instance is specified for an IKE profile, and the device forwards protected data to the VPN instance where the interface receiving the data resides.

11.   (Optional.) Specify a priority for the IKE profile.

priority number

By default, the priority of an IKE profile is 100.

 

Configuring an IKE proposal

An IKE proposal defines a set of attributes describing how IKE negotiation in phase 1 should take place. You can create multiple IKE proposals with different priorities. The priority of an IKE proposal is represented by its sequence number. The lower the sequence number, the higher the priority.

Two peers must have at least one matching IKE proposal for successful IKE negotiation. During IKE negotiation:

·           The initiator sends its IKE proposals to the peer.

¡  If the initiator is using an IPsec policy with an IKE profile, the initiator sends all IKE proposals referenced by the IKE profile to the peer. An IKE proposal specified earlier for the IKE profile has a higher priority.

¡  If the initiator is using an IPsec policy with no IKE profile, the initiator sends all its IKE proposals to the peer. An IKE proposal with a smaller number has a higher priority.

·           The peer searches its own IKE proposals for a match. The search starts from the IKE proposal with the highest priority and proceeds in descending order of priority until a match is found. The matching IKE proposals are used to establish the IKE SA. If all user-defined IKE proposals are found mismatching, the two peers use their default IKE proposals to establish the IKE SA.

Two matching IKE proposals have the same encryption algorithm, authentication method, authentication algorithm, and DH group. The SA lifetime takes the smaller one of the two proposals' SA lifetime settings.

To configure an IKE proposal:

 

Step

Command

Remarks

1.      Enter system view.

system-view

N/A

2.      Create an IKE proposal and enter its view.

ike proposal proposal-number

By default, there is an IKE proposal that is used as the default IKE proposal.

3.      Specify an encryption algorithm for the IKE proposal.

·          In non-FIPS mode:
encryption-algorithm
{ 3des-cbc | aes-cbc-128 | aes-cbc-192 | aes-cbc-256 | des-cbc }

·          In FIPS mode:
encryption-algorithm { aes-cbc-128 | aes-cbc-192 | aes-cbc-256 }

By default:

·          In non-FIPS mode, an IKE proposal uses the 56-bit DES encryption algorithm in CBC mode.

·          In FIPS mode, an IKE proposal uses the 128-bit AES encryption algorithm in CBC mode.

4.      Specify an authentication method for the IKE proposal.

authentication-method { dsa-signature | pre-share | rsa-signature }

By default, an IKE proposal uses the pre-shared key authentication method.

5.      Specify an authentication algorithm for the IKE proposal.

·          In non-FIPS mode:
authentication-algorithm
{ md5 | sha | sha256 | sha384 | sha512 }

·          In FIPS mode:
authentication-algorithm
{ sha | sha256 | sha384 | sha512 }

By default, an IKE proposal uses the HMAC-SHA1 authentication algorithm in non-FIPS mode and the HMAC-SHA256 authentication algorithm in FIPS mode.

6.      Specify a DH group for key negotiation in phase 1.

·          In non-FIPS mode:
dh
{ group1 | group14 | group2 | group24 | group5 }

·          In FIPS mode:
dh group14

By default:

·          In non-FIPS mode, DH group1 (the 768-bit DH group) is used.

·          In FIPS mode, DH group14 (the 2048-bit DH group) is used.

7.      Set the IKE SA lifetime for the IKE proposal.

sa duration seconds

By default, the IKE SA lifetime is 86400 seconds.

 

Configuring an IKE keychain

Perform this task when you configure the IKE to use the pre-shared key for authentication.

Follow these guidelines when you configure an IKE keychain:

1.      Two peers must be configured with the same pre-shared key to pass pre-shared key authentication.

2.      You can specify the local address configured in IPsec policy or IPsec policy template view (using the local-address command) for the IKE keychain to be applied. If no local address is configured, specify the IP address of the interface that references the IPsec policy.

3.      You can specify a priority number for the IKE keychain. To determine the priority of an IKE keychain:

a.    The device examines the existence of the match local address command. An IKE keychain with the match local address command configured has a higher priority.

b.    If a tie exists, the device compares the priority numbers. An IKE keychain with a smaller priority number has a higher priority.

c.    If a tie still exists, the device prefers an IKE keychain configured earlier.

To configure the IKE keychain:

 

Step

Command

Remarks

1.      Enter system view.

system-view

N/A

2.      Create an IKE keychain and enter its view.

ike keychain keychain-name [ vpn-instance vpn-name ]

By default, no IKE keychain exists.

3.      Configure a pre-shared key.

·          In non-FIPS mode:
pre-shared-key
{ address { ipv4-address [ mask | mask-length ] | ipv6 ipv6-address [ prefix-length ] } | hostname host-name } key { cipher cipher-key | simple simple-key }

·          In FIPS mode:
pre-shared-key
{ address { ipv4-address [ mask | mask-length ] | ipv6 ipv6-address [ prefix-length ] } | hostname host-name } key [ cipher cipher-key ]

By default, no pre-shared key is configured.

For security purposes, all pre-shared keys, including those configured in plain text, are saved in cipher text to the configuration file.

4.      (Optional.) Specify a local interface or IP address to which the IKE keychain can be applied.

match local address { interface-type interface-number | { ipv4-address | ipv6 ipv6-address } [ vpn-instance vpn-name ] }

By default, an IKE keychain can be applied to any local interface or IP address.

5.      (Optional.) Specify a priority for the IKE keychain.

priority number

The default priority is 100.

 

Configuring the global identity information

Follow these guidelines when you configure the global identity information for the local IKE:

·           The global identity can be used by the device for all IKE SA negotiations, and the local identity (set by the local-identity command) can be used only by the device that uses the IKE profile.

·           When signature authentication is used, you can set any type of the identity information.

·           When pre-shared key authentication is used, you cannot set the DN as the identity.

To configure the global identity information:

 

Step

Command

Remarks

1.      Enter system view.

system-view

N/A

2.      Configure the global identity to be used by the local end.

ike identity { address { ipv4-address | ipv6 ipv6-address } | dn | fqdn [ fqdn-name ] | user-fqdn [ user-fqdn-name ] }

By default, the IP address of the interface to which the IPsec policy or IPsec policy template is applied is used as the IKE identity.

3.      (Optional.) Configure the local device to always obtain the identity information from the local certificate for signature authentication.

ike signature-identity from-certificate

By default, the local end uses the identity information specified by local-identity or ike identity for signature authentication.

Configure this command when the aggressive mode and signature authentication are used and the device interconnects with a Comware 5-based peer device. Comware 5 supports only DN for signature authentication.

 

Configuring the IKE keepalive feature

IKE sends keepalive packets to query the liveness of the peer. If the peer is configured with the keepalive timeout time, you must configure the keepalive interval on the local device. If the peer receives no keepalive packets during the timeout time, the IKE SA is deleted along with the IPsec SAs it negotiated.

Follow these guidelines when you configure the IKE keepalive feature:

·           Configure IKE DPD instead of the IKE keepalive feature unless IKE DPD is not supported on the peer. The IKE keepalive feature sends keepalives at regular intervals, which consumes network bandwidth and resources.

·           The keepalive timeout time configured on the local device must be longer than the keepalive interval configured at the peer. Since it seldom occurs that more than three consecutive packets are lost on a network, you can set the keepalive timeout three times as long as the keepalive interval.

To configure the IKE keepalive feature:

 

Step

Command

Remarks

1.      Enter system view.

system-view

N/A

2.      Set the IKE SA keepalive interval.

ike keepalive interval seconds

By default, no keepalives are sent to the peer.

3.      Set the IKE SA keepalive timeout time.

ike keepalive timeout seconds

By default, IKE SA keepalive never times out.

 

Configuring the IKE NAT keepalive feature

If IPsec traffic passes through a NAT device, you must configure the NAT traversal feature. If no packet travels across an IPsec tunnel in a period of time, the NAT sessions are aged and deleted, disabling the tunnel from transmitting data to the intended end. To prevent NAT sessions from being aged, configure the NAT keepalive feature on the IKE gateway behind the NAT device to send NAT keepalive packets to its peer periodically to keep the NAT session alive.

To configure the IKE NAT keepalive feature:

 

Step

Command

Remarks

1.      Enter system view.

system-view

N/A

2.      Set the IKE NAT keepalive interval.

ike nat-keepalive seconds

The default interval is 20 seconds.

 

Configuring IKE DPD

DPD detects dead peers. It can operate in periodic mode or on-demand mode.

·           Periodic DPD—Sends a DPD message at regular intervals. It features an earlier detection of dead peers, but consumes more bandwidth and CPU.

·           On-demand DPD—Sends a DPD message based on traffic. When the device has traffic to send and is not aware of the liveness of the peer, it sends a DPD message to query the status of the peer. If the device has no traffic to send, it never sends DPD messages. As a best practice, use the on-demand mode.

The IKE DPD works as follows:

1.      The local device sends a DPD message to the peer, and waits for a response from the peer.

2.      If the peer does not respond within the retry interval specified by the retry seconds parameter, the local device resends the message.

3.      If still no response is received within the retry interval, the local end sends the DPD message again. The system allows a maximum of two retries.

4.      If the local device receives no response after two retries, the device considers the peer to be dead, and deletes the IKE SA along with the IPsec SAs it negotiated.

5.      If the local device receives a response from the peer during the detection process, the peer is considered alive. The local device performs a DPD detection again when the triggering interval is reached or it has traffic to send, depending on the DPD mode.

Follow these guidelines when you configure the IKE DPD feature:

·           When DPD settings are configured in both IKE profile view and system view, the DPD settings in IKE profile view apply. If DPD is not configured in IKE profile view, the DPD settings in system view apply.

·           It is a good practice to set the triggering interval longer than the retry interval so that a DPD detection is not triggered during a DPD retry.

To configure IKE DPD:

 

Step

Command

Remarks

1.      Enter system view.

system-view

N/A

2.      Enable sending IKE DPD messages.

ike dpd interval interval-seconds [ retry seconds ] { on-demand | periodic }

By default, IKE DPD is disabled.

 

Enabling invalid SPI recovery

An IPsec "black hole" occurs when one IPsec peer fails (for example, a peer can fail if a reboot occurs). One peer fails and loses its SAs with the other peer. When an IPsec peer receives a data packet for which it cannot find an SA, an invalid SPI is encountered. The peer drops the data packet and tries to send an SPI invalid notification to the data originator. This notification is sent by using the IKE SA. Because no IKE SA is available, the notification is not sent. The originating peer continues sending the data by using the IPsec SA that has the invalid SPI, and the receiving peer keeps dropping the traffic.

The invalid SPI recovery feature enables the receiving peer to set up an IKE SA with the originator so that an SPI invalid notification can be sent. Upon receiving the notification, the originating peer deletes the IPsec SA that has the invalid SPI. If the originator has data to send, new SAs will be set up.

Use caution when you enable the invalid SPI recovery feature because using this feature can result in a DoS attack. Attackers can make a great number of invalid SPI notifications to the same peer.

To enable invalid SPI recovery:

 

Step

Command

Remarks

1.      Enter system view.

system-view

N/A

2.      Enable invalid SPI recovery.

ike invalid-spi-recovery enable

By default, the invalid SPI recovery is disabled.

 

Setting the maximum number of IKE SAs

You can set the maximum number of half-open IKE SAs and the maximum number of established IKE SAs.

·           The supported maximum number of half-open IKE SAs depends on the device's processing capability. Adjust the maximum number of half-open IKE SAs to make full use of the device's processing capability without affecting the IKE SA negotiation efficiency.

·           The supported maximum number of established IKE SAs depends on the device's memory space. Adjust the maximum number of established IKE SAs to make full use of the device's memory space without affecting other applications in the system.

To set the limit on the number of IKE SAs:

 

Step

Command

Remarks

1.      Enter system view.

system-view

N/A

2.      Set the maximum number of half-open IKE SAs and the maximum number of established IKE SAs.

ike limit { max-negotiating-sa negotiation-limit | max-sa sa-limit }

By default, there is no limit to the maximum number of IKE SAs.

 

Configuring SNMP notifications for IKE

After you enable SNMP notifications for IKE, the IKE module notifies the NMS of important module events. The notifications are sent to the device's SNMP module. You can configure the notification transmission parameters for the SNMP module to specify how the SNMP module displays notifications. For more information about SNMP notifications, see Network Management and Monitoring Configuration Guide.

To generate and output SNMP notifications for a specific IKE failure or event type, perform the following tasks:

1.      Enable SNMP notifications for IKE globally.

2.      Enable SNMP notifications for the failure or event type.

To configure SNMP notifications for IKE:

 

Step

Command

Remarks

1.      Enter system view

system-view

N/A

2.      Enable SNMP notifications for IKE globally.

snmp-agent trap enable ike global

By default, SNMP notifications for IKE are enabled.

3.      Enable SNMP notifications for the specified failure or event types.

snmp-agent trap enable ike [ attr-not-support | auth-failure | cert-type-unsupport | cert-unavailable | decrypt-failure | encrypt-failure | invalid-cert-auth | invalid-cookie | invalid-id | invalid-proposal | invalid-protocol | invalid-sign | no-sa-failure | proposal-add | proposal–delete | tunnel-start | tunnel-stop | unsupport-exch-type ] *

By default, SNMP notifications for all failure and event types are enabled.

 

Displaying and maintaining IKE

Execute display commands in any view and reset commands in user view.

 

Task

Command

Display configuration information about all IKE proposals.

display ike proposal

Display information about the current IKE SAs.

display ike sa [ verbose [ connection-id connection-id | remote-address [ ipv6 ] remote-address [ vpn-instance vpn-name ] ] ]

Display IKE statistics.

display ike statistics

Delete IKE SAs.

reset ike sa [ connection-id connection-id ]

Clear IKE MIB statistics.

reset ike statistics

 

IKE configuration examples

Main mode IKE with pre-shared key authentication configuration example

Network requirements

As shown in Figure 9, configure an IPsec tunnel that uses IKE negotiation between Switch A and Switch B to secure the communication.

Configure Switch A and Switch B to use the default IKE proposal for the IKE negotiation to set up the IPsec SA. Configure the two switches to use the pre-shared key authentication method.

Figure 9 Network diagram

 

Configuration procedure

Make sure Switch A and Switch B can reach each other.

1.      Configure Switch A:

# Assign an IP address to VLAN-interface 1.

<SwitchA> system-view

[SwitchA] interface vlan-interface 1

[SwitchA-vlan-interface1] ip address 1.1.1.1 255.255.0.0

[SwitchA-vlan-interface1] quit

# Configure ACL 3101 to identify traffic between Switch A and Switch B.

[SwitchA] acl number 3101

[SwitchA-acl-adv-3101] rule 0 permit ip source 1.1.1.1 0 destination 2.2.2.2 0

[SwitchA-acl-adv-3101] quit

# Create IPsec transform set tran1.

[SwitchA] ipsec transform-set tran1

# Set the packet encapsulation mode to tunnel.

[SwitchA-ipsec-transform-set-tran1] encapsulation-mode tunnel

# Use the ESP protocol for the IPsec transform set.

[SwitchA-ipsec-transform-set-tran1] protocol esp

# Specify the encryption and authentication algorithms.

[SwitchA-ipsec-transform-set-tran1] esp encryption-algorithm aes-cbc-192

[SwitchA-ipsec-transform-set-tran1] esp authentication-algorithm sha1

[SwitchA-ipsec-transform-set-tran1] quit

# Create IKE keychain keychain1.

[SwitchA] ike keychain keychain1

# Specify 12345zxcvb!@#$%ZXCVB in plain text as the pre-shared key.

[SwitchA-ike-keychain-keychain1] pre-shared-key address 2.2.2.2 255.255.0.0 key simple 12345zxcvb!@#$%ZXCVB

[SwitchA-ike-keychain-keychain1] quit

# Create IKE profile profile1.

[SwitchA] ike profile profile1

# Specify IKE keychain keychain1.

[SwitchA-ike-profile-profile1] keychain keychain1

# Configure a peer ID with the identity type of IP address and the value of 2.2.2.2.

[SwitchA-ike-profile-profile1] match remote identity address 2.2.2.2 255.255.0.0

[SwitchA-ike-profile-profile1] quit

# Create an IKE-based IPsec policy entry. Specify the policy name as map1 and set the sequence number to 10.

[SwitchA] ipsec policy map1 10 isakmp

# Specify the remote IP address 2.2.2.2 for the IPsec tunnel.

[SwitchA-ipsec-policy-isakmp-map1-10] remote-address 2.2.2.2

# Reference ACL 3101 to identify the traffic to be protected.

[SwitchA-ipsec-policy-isakmp-map1-10] security acl 3101

# Reference IPsec transform set tran1 for the IPsec policy.

[SwitchA-ipsec-policy-isakmp-map1-10] transform-set tran1

# Specify IKE profile profile1 for the IPsec policy.

[SwitchA-ipsec-policy-isakmp-map1-10] ike-profile profile1

[SwitchA-ipsec-policy-isakmp-map1-10] quit

# Specify slot 1 for forwarding traffic on VLAN-interface 1.

[SwitchA] interface vlan-interface 1

[SwitchA-Vlan-interface1] service slot 1

# Apply IPsec policy map1 to VLAN-interface 1.

[SwitchA-Vlan-interface1] ipsec apply policy map1

2.      Configure Switch B:

# Assign an IP address to VLAN-interface 1.

<SwitchB> system-view

[SwitchB] interface Vlan-interface1

[SwitchB-Vlan-interface1] ip address 2.2.2.2 255.255.0.0

[SwitchB-Vlan-interface1] quit

# Configure ACL 3101 to identify traffic between Switch B and Switch A.

[SwitchB] acl number 3101

[SwitchB-acl-adv-3101] rule 0 permit ip source 2.2.2.2 0 destination 1.1.1.0 0

[SwitchB-acl-adv-3101] quit

# Create IPsec transform set tran1.

[SwitchB] ipsec transform-set tran1

# Set the packet encapsulation mode to tunnel.

[SwitchB-ipsec-transform-set-tran1] encapsulation-mode tunnel

# Use the ESP protocol for the IPsec transform set.

[SwitchB-ipsec-transform-set-tran1] protocol esp

# Specify the encryption and authentication algorithms.

[SwitchB-ipsec-transform-set-tran1] esp encryption-algorithm aes-cbc-192

[SwitchB-ipsec-transform-set-tran1] esp authentication-algorithm sha1

[SwitchB-ipsec-transform-set-tran1] quit

# Create IKE keychain keychain1.

[SwitchB]ike keychain keychain1

# Specify 12345zxcvb!@#$%ZXCVB in plain text as the pre-shared key.

[SwitchB-ike-keychain-keychain1] pre-shared-key address 1.1.1.1 255.255.0.0 key simple 12345zxcvb!@#$%ZXCVB

[SwitchB-ike-keychain-keychain1] quit

# Create IKE profile profile1.

[SwitchB] ike profile profile1

# Specify IKE keychain keychain1

[SwitchB-ike-profile-profile1] keychain keychain1

# Configure a peer ID with the identity type of IP address and the value of 1.1.1.1.

[SwitchB-ike-profile-profile1] match remote identity address 1.1.1.1 255.255.0.0

[SwitchB-ike-profile-profile1] quit

# Create an IKE-based IPsec policy entry. Specify the policy name as use1 and set the sequence number to 10.

[SwitchB] ipsec policy use1 10 isakmp

# Specify the remote IP address 1.1.1.1 for the IPsec tunnel.

[SwitchB-ipsec-policy-isakmp-use1-10] remote-address 1.1.1.1

# Reference ACL 3101 to identify the traffic to be protected.

[SwitchB-ipsec-policy-isakmp-use1-10] security acl 3101

# Reference IPsec transform set tran1 for the IPsec policy.

[SwitchB-ipsec-policy-isakmp-use1-10] transform-set tran1

# Specify IKE profile profile1 for the IPsec policy.

[SwitchB-ipsec-policy-isakmp-use1-10] ike-profile profile1

[SwitchB-ipsec-policy-isakmp-use1-10] quit

# Specify slot 1 for forwarding traffic on VLAN-interface 1.

[SwitchB] interface vlan-interface 1

[SwitchB-Vlan-interface1] service slot 1

# Apply IPsec policy use1 to VLAN-interface 1.

[SwitchB-Vlan-interface1] ipsec apply policy use1

Verifying the configuration

# Initiate a connection from Switch A to Switch B to trigger IKE negotiation. After IPsec SAs are successfully negotiated by IKE, traffic between the two switches is IPsec protected.

Troubleshooting IKE

IKE negotiation failed because no matching IKE proposals were found

Symptom

1.      The IKE SA is in Unknown state.

<Sysname> display ike sa

    Connection-ID   Remote                Flag         DOI

------------------------------------------------------------------

    1               192.168.222.5         Unknown      IPSEC

Flags:

RD--READY RL--REPLACED FD-FADING

2.      When IKE event debugging and packet debugging are enabled, the following messages appear:

IKE event debugging message:

The attributes are unacceptable.

IKE packet debugging message:

Construct notification packet: NO_PROPOSAL_CHOSEN.

Analysis

Certain IKE proposal settings are incorrect.

Solution

1.      Examine the IKE proposal configuration to see whether the two ends have matching IKE proposals.

2.      Modify the IKE proposal configuration to make sure the two ends have matching IKE proposals.

IKE negotiation failed because no IKE proposals or IKE keychains are specified correctly

Symptom

1.      The IKE SA is in Unknown state.

<Sysname> display ike sa

    Connection-ID   Remote                Flag         DOI

------------------------------------------------------------------

    1               192.168.222.5         Unknown      IPSEC

Flags:

RD--READY RL--REPLACED FD-FADING

2.      The following IKE event debugging or packet debugging message appeared:

IKE event debugging message:

Notification PAYLOAD_MALFORMED is received.

IKE packet debugging message:

Construct notification packet: PAYLOAD_MALFORMED.

Analysis

·           If the following debugging information appeared, the matched IKE profile is not referencing the matched IKE proposal:

Failed to find proposal 1 in profile profile1.

·           If the following debugging information appeared, the matched IKE profile is not referencing the matched IKE keychain:

Failed to find keychain keychain1 in profile profile1.

Solution

·           Verify that the matched IKE proposal (IKE proposal 1 in this debugging message example) is referenced by the IKE profile (IKE profile 1 in the example).

·           Verify that the matched IKE keychain (IKE keychain 1 in this debugging message example) is referenced by the IKE profile (IKE profile 1 in the example).

IPsec SA negotiation failed because no matching IPsec transform sets were found

Symptom

1.      The display ike sa command shows that the IKE SA negotiation succeeded and the IKE SA is in RD state, but the display ipsec sa command shows that the expected IPsec SA has not been negotiated yet.

2.      The following IKE debugging message appeared:

The attributes are unacceptable.

Or:

Construct notification packet: NO_PROPOSAL_CHOSEN.

Analysis

Certain IPsec policy settings are incorrect.

Solution

1.      Examine the IPsec configuration to see whether the two ends have matching IPsec transform sets.

2.      Modify the IPsec configuration to make sure the two ends have matching IPsec transform sets.

IPsec SA negotiation failed due to invalid identity information

Symptom

1.      The display ike sa command shows that the IKE SA negotiation succeeded and the IKE SA is in RD state, but the display ipsec sa command shows that the expected IPsec SA has not been negotiated yet.

2.      The following IKE debugging message appeared:

Notification INVALID_ID_INFORMATION is received.

Or:

Failed to get IPsec policy when renegotiating IPsec SA. Delete IPsec SA.

Construct notification packet: INVALID_ID_INFORMATION.

Analysis

Certain IPsec policy settings of the responder are incorrect. Verify the settings as follows:

1.      Use the display ike sa verbose command to verify that matching IKE profiles were found in IKE negotiation phase 1. If no matching IKE profiles were found and the IPsec policy is referencing an IKE profile, the IPsec SA negotiation fails.

# Verify that matching IKE profiles were found in IKE negotiation phase 1.

<Sysname> display ike sa verbose

   -----------------------------------------------

   Connection ID: 3

   Outside VPN:

   Inside VPN:

   Profile:

   Transmitting entity: Responder

   -----------------------------------------------

   Local IP: 192.168.222.5

   Local ID type: IPV4_ADDR

   Local ID: 192.168.222.5

 

   Remote IP: 192.168.222.71

   Remote ID type: IPV4_ADDR

   Remote ID: 192.168.222.71

 

   Authentication-method: PRE-SHARED-KEY

   Authentication-algorithm: MD5

   Encryption-algorithm: 3DES-CBC

 

   Life duration(sec): 86400

   Remaining key duration(sec): 85847

   Exchange-mode: Main

   Diffie-Hellman group: Group 1

   NAT traversal: Not detected

# Verify that the IPsec policy is referencing an IKE profile.

[Sysname] display ipsec policy

-------------------------------------------

IPsec Policy: policy1

Interface: Vlan-interface1

-------------------------------------------

 

  -----------------------------

  Sequence number: 1

  Mode: isakmp

  -----------------------------

  Description:

  Security data flow: 3000

  Selector mode: aggregation

  Local address: 192.168.222.5

  Remote address: 192.168.222.71

  Transform set:  transform1

  IKE profile: profile1

  SA duration(time based):

  SA duration(traffic based):

  SA idle time:

2.      Verify that the ACL referenced by the IPsec policy is correctly configured. If the flow range defined by the responder's ACL is smaller than that defined by the initiator's ACL, IPsec proposal matching will fail.

For example, if the initiator's ACL defines a flow from one network segment to another but the responder's ACL defines a flow from one host to another host, IPsec proposal matching will fail.

# On the initiator:

[Sysname] display acl 3000

Advanced ACL  3000, named -none-, 2 rules,

ACL's step is 5

 rule 0 permit ip source 192.168.222.0 0.0.0.255 destination 192.168.222.0 0.0.0.255

# On the responder:

[Sysname] display acl 3000

Advanced ACL  3000, named -none-, 2 rules,

ACL's step is 5

 rule 0 permit ip source 192.168.222.71 0 destination 192.168.222.5 0

3.      Verify that the IPsec policy has a remote address and an IPsec transform set configured and that the IPsec transform set has all necessary settings configured.

If, for example, the IPsec policy has no remote address configured, the IPsec SA negotiation will fail:

[Sysname] display ipsec policy

-------------------------------------------

IPsec Policy: policy1

Interface: Vlan-interface1

-------------------------------------------

 

  -----------------------------

  Sequence number: 1

  Mode: isakmp

  -----------------------------

  Description:

  Security data flow: 3000

  Selector mode: aggregation

  Local address: 192.168.222.5

  Remote address:

  Transform set:  transform1

  IKE profile: profile1

  SA duration(time based):

  SA duration(traffic based):

  SA idle time:

Solution

1.      If no matching IKE profiles were found and the IPsec policy is referencing an IKE profile, remove the reference.

2.      If the flow range defined by the responder's ACL is smaller than that defined by the initiator's ACL, modify the responder's ACL so the ACL defines a flow range equal to or greater than that of the initiator's ACL.

For example:

[Sysname] display acl 3000

Advanced ACL  3000, named -none-, 2 rules,

ACL's step is 5

 rule 0 permit ip source 192.168.222.0 0.0.0.255 destination 192.168.222.0 0.0.0.255

3.      Configure the missing settings (for example, the remote address).


Configuring IKEv2

Overview

Internet Key Exchange version 2 (IKEv2) is an enhanced version of IKEv1. The same as IKEv1, IKEv2 has a set of self-protection mechanisms and can be used on insecure networks for reliable identity authentication, key distribution, and IPsec SA negotiation. IKEv2 provides stronger protection against attacks and higher key exchange ability and needs less message exchanges than IKEv1.

IKEv2 negotiation process

Compared with IKEv1, IKEv2 simplifies the negotiation process and is much more efficient.

IKEv2 defines three types of exchanges: initial exchanges, CREATE_CHILD_SA exchange, and INFORMATIONAL exchange.

As shown in Figure 10, IKEv2 uses two exchanges during the initial exchange process: IKE_SA_INIT and IKE_AUTH, each with two messages.

·           IKE_SA_INIT exchange—Negotiates IKE SA parameters and exchanges keys.

·           IKE_AUTH exchange—Authenticates the identity of the peer and establishes IPsec SAs.

After the four-message initial exchanges, IKEv2 sets up one IKE SA and one pair of IPsec SAs. For IKEv1 to set up one IKE SA and one pair of IPsec SAs, it must go through two phases that use a minimum of six messages.

To set up one more pair of IPsec SAs within the IKE SA, IKEv2 goes on to perform an additional two-message exchange—the CREATE_CHILD_SA exchange. One CREATE_CHILD_SA exchange creates one pair of IPsec SAs. IKEv2 also uses the CREATE_CHILD_SA exchange to rekey IKE SAs and Child SAs.

IKEv2 uses the INFORMATIONAL exchange to convey control messages about errors and notifications.

Figure 10 IKEv2 Initial exchange process

 

New features in IKEv2

DH guessing

In the IKE_SA_INIT exchange, the initiator guesses the DH group that the responder is most likely to use and sends it in an IKE_SA_INIT request message. If the initiator's guess is correct, the responder responds with an IKE_SA_INIT response message and the IKE_SA_INIT exchange is finished. If the guess is wrong, the responder responds with an INVALID_KE_PAYLOAD message that contains the DH group that it wants to use. The initiator then uses the DH group selected by the responder to reinitiate the IKE_SA_INIT exchange. The DH guessing mechanism allows for more flexible DH group configuration and enables the initiator to adapt to different responders.

Cookie challenging

Messages for the IKE_SA_INIT exchange are in plain text. An IKEv1 responder cannot confirm the validity of the initiators and must maintain half-open IKE SAs, which makes the responder susceptible to DoS attacks. An attacker can send a large number of IKE_SA_INIT requests with forged source IP addresses to the responder, exhausting the responder's system resources.

IKEv2 introduces the cookie challenging mechanism to prevent such DoS attacks. When an IKEv2 responder maintains a threshold number of half-open IKE SAs, it starts the cookie challenging mechanism. The responder generates a cookie and includes it in the response sent to the initiator. If the initiator initiates a new IKE_SA_INIT request that carries the correct cookie, the responder considers the initiator valid and proceeds with the negotiation. If the carried cookie is incorrect, the responder terminates the negotiation.

The cookie challenging mechanism automatically stops working when the number of half-open IKE SAs drops below the threshold.

IKEv2 SA rekeying

For security purposes, both IKE SAs and IPsec SAs have a lifetime and must be rekeyed when the lifetime expires. An IKEv1 SA lifetime is negotiated. An IKEv2 SA lifetime, in contrast, is configured. If two peers are configured with different lifetimes, the peer with the shorter lifetime always initiates the SA rekeying. This mechanism reduces the possibility that two peers will simultaneously initiate a rekeying. Simultaneous rekeying results in redundant SAs and SA status inconsistency on the two peers.

IKEv2 message retransmission

Unlike IKEv1 messages, IKEv2 messages appear in request/response pairs. IKEv2 uses the Message ID field in the message header to identify the request/response pair. If an initiator sends a request but receives no response with the same Message ID value within a specific period of time, the initiator retransmits the request.

It is always the IKEv2 initiator that initiates the retransmission, and the retransmitted message must use the same Message ID value.

Protocols and standards

·           RFC 2408, Internet Security Association and Key Management Protocol (ISAKMP)

·           RFC 4306, Internet Key Exchange (IKEv2) Protocol

·           RFC 4718, IKEv2 Clarifications and Implementation Guidelines

·           RFC 2412, The OAKLEY Key Determination Protocol

·           RFC 5996, Internet Key Exchange Protocol Version 2 (IKEv2)

Feature and software version compatibility

IKEv2 configuration task list

Determine the following parameters prior to IKEv2 configuration:

·           The strength of the algorithms for IKEv2 negotiation, including the encryption algorithms, integrity protection algorithms, PRF algorithms, and DH groups. Different algorithms provide different levels of protection. A stronger algorithm means better resistance to decryption of protected data but requires more resources. Typically, the longer the key, the stronger the algorithm.

·           The local and remote identity authentication methods.

¡  To use the pre-shared key authentication method, you must determine the pre-shared key.

¡  To use the RSA digital signature authentication method, you must determine the PKI domain for the local end to use. For information about PKI, see "Configuring PKI."

To configure IKEv2, perform the following tasks:

 

Tasks at a glance

Remarks

(Required.) Configuring an IKEv2 profile

N/A

(Required.) Configuring an IKEv2 policy

N/A

(Optional.) Configuring an IKEv2 proposal

If you specify an IKEv2 proposal in an IKEv2 policy, you must configure the IKEv2 proposal.

Configuring an IKEv2 keychain

Required when either end or both ends use the pre-shared key authentication method.

Configure global IKEv2 parameters

·          (Optional.) Enabling the cookie challenging feature

·          (Optional.) Configuring the IKEv2 DPD feature

·          (Optional.) Configuring the IKEv2 NAT keepalive feature

The cookie challenging feature takes effect only on IKEv2 responders.

 

Configuring an IKEv2 profile

An IKEv2 profile is intended to provide a set of parameters for IKEv2 negotiation. To configure an IKEv2 profile, perform the following tasks:

1.      Specify the local and remote identity authentication methods.

The local and remote identity authentication methods must both be specified and they can be different. You can specify only one local identity authentication method and multiple remote identity authentication methods.

2.      Configure the IKEv2 keychain or PKI domain for the IKEv2 profile to use:

¡  To use digital signature authentication, configure a PKI domain.

¡  To use pre-shared key authentication, configure an IKEv2 keychain.

3.      Configure the local ID, the ID that the device uses to identify itself to the peer during IKEv2 negotiation:

¡  For digital signature authentication, the device can use an ID of any type. If the local ID is an IP address that is different from the IP address in the local certificate, the device uses the FQDN as the local ID. The FQDN is the device name configured by using the sysname command.

¡  For pre-shared key authentication, the device can use an ID of any type other than the DN.

4.      Configure peer IDs.

The device compares the received peer ID with the peer IDs of its local IKEv2 profiles. If a match is found, it uses the IKEv2 profile with the matching peer ID for IKEv2 negotiation. IKEv2 profiles will be compared in descending order of their priorities.

5.      Specify a local interface or IP address for the IKEv2 profile so the profile can be applied only to the specified interface or IP address. For this task, specify the local address configured in IPsec policy or IPsec policy template view (using the local-address command). If no local address is configured, specify the IP address of the interface that uses the IPsec policy.

6.      Specify a priority number for the IKEv2 profile. To determine the priority of an IKEv2 profile:

a.    First, the device examines the existence of the match local command. An IKEv2 profile with the match local command configured has a higher priority.

b.    If a tie exists, the device compares the priority numbers. An IKEv2 profile with a smaller priority number has a higher priority.

c.    If a tie still exists, the device prefers an IKEv2 profile configured earlier.

7.      Specify a VPN instance for the IKEv2 profile. The IKEv2 profile is used for IKEv2 negotiation only on the interfaces that belong to the VPN instance.

8.      Configure the IKEv2 SA lifetime.

The local and remote ends can use different IKEv2 SA lifetimes. They do not negotiate the lifetime. The end with a smaller SA lifetime will initiate an SA negotiation when the lifetime expires.

9.      Configure IKEv2 DPD to detect dead IKEv2 peers. You can also configure this feature in system view. If you configure IKEv2 DPD in both views, the IKEv2 DPD settings in IKEv2 profile view apply. If you do not configure IKEv2 DPD in IKEv2 profile view, the IKEv2 DPD settings in system view apply.

10.    Specify an inside VPN instance. This setting determines where the device should forward received IPsec packets after it de-encapsulates them. If you specify an inside VPN instance, the device looks for a route in the specified VPN instance to forward the packets. If you do not specify an inside VPN instance, the internal and external networks are in the same VPN instance. The device looks for a route in this VPN instance to forward the packets.

11.    Configure the NAT keepalive interval.

Configure this task when the device is behind a NAT gateway. The device sends NAT keepalive packets regularly to its peer to prevent the NAT session from being aged because of no matching traffic.

12.    Enable the configuration exchange feature.

The configuration exchange feature enables the local and remote ends to exchange configuration data, such as gateway address, internal IP address, and route. The exchange includes data request and response, and data push and response.

This feature typically applies to scenarios where branches and the headquarters communicate through virtual tunnels.

This feature enables the IPsec gateway at a branch to send IP address requests to the IPsec gateway at the headquarters. When the headquarters receives the request, it sends an IP address to the branch in the response packet. The headquarters can also actively push an IP address to the branch. The branch uses the allocated IP address as the IP address of the virtual tunnel to communicate with the headquarters.

To configure an IKEv2 profile:

 

Step

Command

Remarks

1.      Enter system view.

system-view

N/A

2.      Create an IKEv2 profile and enter IKEv2 profile view.

ikev2 profile profile-name

By default, no IKEv2 profiles exist.

3.      Configure the local and remote identity authentication methods.

authentication-method { local | remote } { dsa-signature | ecdsa-signature | pre-share | rsa-signature }

By default, no local or remote identity authentication method is configured.

4.      Specify a keychain.

keychain keychain-name

By default, no keychain is specified for an IKEv2 profile.

Perform this task when the pre-shared key authentication method is specified.

5.      Specify a PKI domain.

certificate domain domain-name [ sign | verify ]

By default, the device uses PKI domains configured in system view.

Perform this task when the digital signature authentication method is specified.

6.      Configure the local ID.

identity local { address { ipv4-address | ipv6 ipv6-address } | dn | email email-string | fqdn fqdn-name | key-id key-id-string }

By default, no local ID is configured, and the device uses the IP address of the interface where the IPsec policy applies as the local ID.

7.      Configure peer IDs.

match remote { certificate policy-name | identity { address { { ipv4-address [ mask | mask-length ] | range low-ipv4-address high-ipv4-address } | ipv6 { ipv6-address [ prefix-length ] | range low-ipv6-address high-ipv6-address } } | fqdn fqdn-name | email email-string | key-id key-id-string } }

By default, no peer ID is configured.

You must configure a minimum of one peer ID on each of the two peers.

8.      (Optional.) Specify the local interface or IP address to which the IKEv2 profile can be applied.

match local address { interface-type interface-number | ipv4-address | ipv6 ipv6-address }

By default, an IKEv2 profile can be applied to any local interface or IP address.

9.      (Optional.) Specify a priority for the IKEv2 profile.

priority priority

By default, the priority of an IKEv2 profile is 100.

10.   (Optional.) Specify a VPN instance for the IKEv2 profile.

match vrf { name vrf-name | any }

By default, an IKEv2 profile belongs to the public network.

11.   (Optional.) Set the IKEv2 SA lifetime for the IKEv2 profile.

sa duration seconds

By default, the IKEv2 SA lifetime is 86400 seconds.

12.   (Optional.) Configure the DPD feature for the IKEv2 profile.

dpd interval interval [ retry seconds ] { on-demand | periodic }

By default, DPD is disabled for an IKEv2 profile. The global DPD settings in system view are used. If DPD is also disabled in system view, the device does not perform DPD.

13.   (Optional.) Specify an inside VPN instance for the IKEv2 profile.

inside-vrf vrf-name

By default, no inside VPN instance is specified for an IKEv2 profile. The internal and external networks are in the same VPN instance. The device forwards protected data to this VPN instance.

14.   (Optional.) Set the IKEv2 NAT keepalive interval.

nat-keepalive seconds

By default, the global IKEv2 NAT keepalive setting is used.

15.   (Optional.) Enable the configuration exchange feature.

config-exchange { request | set { accept | send } }

By default, all configuration exchange options are disabled.

 

Configuring an IKEv2 policy

During the IKE_SA_INIT exchange, each end tries to find a matching IKEv2 policy, using the IP address of the local security gateway as the matching criterion.

·           If IKEv2 policies are configured, IKEv2 searches for an IKEv2 policy that uses the IP address of the local security gateway. If no IKEv2 policy uses the IP address or the policy is using an incomplete proposal, the IKE_SA_INIT exchange fails.

·           If no IKEv2 policy is configured, IKEv2 uses the system default IKEv2 policy default.

The device matches IKEv2 policies in the descending order of their priorities. To determine the priority of an IKEv2 policy:

1.      First, the device examines the existence of the match local address command. An IKEv2 policy with the match local address command configured has a higher priority.

2.      If a tie exists, the device compares the priority numbers. An IKEv2 policy with a smaller priority number has a higher priority.

3.      If a tie still exists, the device prefers an IKEv2 policy configured earlier.

To configure an IKEv2 policy:

 

Step

Command

Remarks

1.      Enter system view.

system-view

N/A

2.      Create an IKEv2 policy and enter IKEv2 policy view.

ikev2 policy policy-name

By default, an IKEv2 policy named default exists.

3.      Specify the local interface or address used for IKEv2 policy matching.

match local address { interface-type interface-number | ipv4-address | ipv6 ipv6-address }

By default, no local interface or address is used for IKEv2 policy matching, and the policy matches any local interface or address.

4.      Specify a VPN instance for IKEv2 policy matching.

match vrf { name vrf-name | any }

By default, no VPN instance is specified for IKEv2 policy matching. The IKEv2 policy matches all local addresses in the public network.

5.      Specify an IKEv2 proposal for the IKEv2 policy.

proposal proposal-name

By default, no IKEv2 proposal is specified for an IKEv2 policy.

6.      Specify a priority for the IKEv2 policy.

priority priority

By default, the priority of an IKEv2 policy is 100.

 

Configuring an IKEv2 proposal

An IKEv2 proposal contains security parameters used in IKE_SA_INIT exchanges, including the encryption algorithms, integrity protection algorithms, PRF algorithms, and DH groups. An algorithm specified earlier has a higher priority.

A complete IKEv2 proposal must have at least one set of security parameters, including one encryption algorithm, one integrity protection algorithm, one PRF algorithm, and one DH group.

You can specify multiple IKEv2 proposals for an IKEv2 policy. A proposal specified earlier has a higher priority.

To configure an IKEv2 proposal:

 

Step

Command

Remarks

1.      Enter system view.

system-view

N/A

2.      Create an IKEv2 proposal and enter IKEv2 proposal view.

ikev2 proposal proposal-name

By default, an IKEv2 proposal named default exists.

In non-FIPS mode, the default proposal uses the following settings:

·          Encryption algorithms AES-CBC-128 and 3DES.

·          Integrity protection algorithms HMAC-SHA1 and HMAC-MD5.

·          PRF algorithms HMAC-SHA1 and HMAC-MD5.

·          DH groups 2 and 5.

In FIPS mode, the default proposal uses the following settings:

·          Encryption algorithms AES-CBC-128 and AES-CTR-128.

·          Integrity protection algorithms HMAC-SHA1 and HMAC-SHA256.

·          PRF algorithms HMAC-SHA1 and HMAC-SHA256.

·          DH groups 14 and 19.

3.      Specify the encryption algorithms.

In non-FIPS mode:

encryption { 3des-cbc | aes-cbc-128 | aes-cbc-192 | aes-cbc-256 | aes-ctr-128 | aes-ctr-192 | aes-ctr-256 | camellia-cbc-128 | camellia-cbc-192 | camellia-cbc-256 | des-cbc } *

In FIPS mode:

encryption { aes-cbc-128 | aes-cbc-192 | aes-cbc-256 | aes-ctr-128 | aes-ctr-192 | aes-ctr-256 } *

By default, an IKEv2 proposal does not have any encryption algorithms.

4.      Specify the integrity protection algorithms.

In non-FIPS mode:

integrity { aes-xcbc-mac | md5 | sha1 | sha256 | sha384 | sha512 } *

In FIPS mode:

integrity { sha1 | sha256 | sha384 | sha512 } *

By default, an IKEv2 proposal does not have any integrity protection algorithms.

5.      Specify the PRF algorithms.

In non-FIPS mode:

prf { aes-xcbc-mac | md5 | sha1 | sha256 | sha384 | sha512 } *

In FIPS mode:

prf { sha1 | sha256 | sha384 | sha512 } *

By default, an IKEv2 proposal uses the integrity protection algorithms as the PRF algorithms.

6.      Specify the DH groups.

In non-FIPS mode:

dh { group1 | group14 | group2 | group24 | group5 | group19 | group20 } *

In FIPS mode:

dh { group14 | group24 | group19 | group20 } *

By default, an IKEv2 proposal does not have any DH groups.

 

Configuring an IKEv2 keychain

An IKEv2 keychain specifies the pre-shared keys used for IKEv2 negotiation.

An IKEv2 keychain can have multiple IKEv2 peers. Each peer has a symmetric pre-shared key or an asymmetric pre-shared key pair, and information for identifying the peer (such as the peer's host name, IP address or address range, or ID).

An IKEv2 negotiation initiator uses the peer host name or IP address/address range as the matching criterion to search for a peer. A responder uses the peer host IP address/address range or ID as the matching criterion to search for a peer.

To configure an IKEv2 keychain:

 

Step

Command

Remarks

1.      Enter system view.

system-view

N/A

2.      Create an IKEv2 keychain and enter IKEv2 keychain view.

ikev2 keychain keychain-name

By default, no IKEv2 keychains exist.

3.      Create an IKEv2 peer and enter IKEv2 peer view.

peer name

By default, no IKEv2 peers exist.

4.      Configure the information for identifying the IKEv2 peer.

·          To configure a host name for the peer:
hostname host-name

·          To configure a host IP address or address range for the peer:
address { ipv4-address [ mask | mask-length ] | ipv6 ipv6-address [ prefix-length ] }

·          To configure an ID for the peer:
identity
{ address { ipv4-address | ipv6 { ipv6-address } } | fqdn fqdn-name | email email-string | key-id key-id-string }

By default, no hostname, host IP address, address range, or identity information is configured for an IKEv2 peer.

You must configure different IP addresses/address ranges for different peers.

5.      Configure a pre-shared key for the peer.

pre-shared-key [ local | remote ] { ciphertext | plaintext } string

By default, an IKEv2 peer does not have a pre-shared key.

 

Configure global IKEv2 parameters

Enabling the cookie challenging feature

Enable cookie challenging on responders to protect them against DoS attacks that use a large number of source IP addresses to forge IKE_SA_INIT requests.

To enable cookie challenging:

 

Step

Command

Remarks

1.      Enter system view.

system-view

N/A

2.      Enable cookie challenging.

ikev2 cookie-challenge number

By default, IKEv2 cookie challenging is disabled.

 

Configuring the IKEv2 DPD feature

IKEv2 DPD detects dead IKEv2 peers in periodic or on-demand mode.

·           Periodic DPD—Verifies the liveness of an IKEv2 peer by sending DPD messages at regular intervals.

·           On-demand DPD—Verifies the liveness of an IKEv2 peer by sending DPD messages before sending data.

¡  Before the device sends data, it identifies the time interval for which the last IPsec packet has been received from the peer. If the time interval exceeds the DPD interval, it sends a DPD message to the peer to detect its liveliness.

¡  If the device has no data to send, it never sends DPD messages.

If you configure IKEv2 DPD in both IKEv2 profile view and system view, the IKEv2 DPD settings in IKEv2 profile view apply. If you do not configure IKEv2 DPD in IKEv2 profile view, the IKEv2 DPD settings in system view apply.

To configure global IKEv2 DPD:

 

Step

Command

Remarks

1.      Enter system view.

system-view

N/A

2.      Configure global IKEv2 DPD.

ikev2 dpd interval interval [ retry seconds ] { on-demand | periodic }

By default, global DPD is disabled.

 

Configuring the IKEv2 NAT keepalive feature

Configure this feature on the IKEv2 gateway behind the NAT device. The gateway then sends NAT keepalive packets regularly to its peer to keep the NAT session alive, so that the peer can access the device.

The NAT keepalive interval must be shorter than the NAT session lifetime.

This feature takes effect after the device detects the NAT device.

To configure the IKEv2 NAT keepalive feature:

 

Step

Command

Remarks

1.      Enter system view.

system-view

N/A

2.      Set the IKEv2 NAT keepalive interval.

ikev2 nat-keepalive seconds

By default, the IKEv2 NAT keepalive interval is 10 seconds.

 

Displaying and maintaining IKEv2

Execute display commands in any view and reset commands in user view.

 

Task

Command

Display the IKEv2 proposal configuration.

display ikev2 proposal [ name | default ]

Display the IKEv2 policy configuration.

display ikev2 policy [ policy-name | default ]

Display the IKEv2 profile configuration.

display ikev2 profile [ profile-name ]

Display the IKEv2 SA information.

display ikev2 sa [ count | [ { local | remote } { ipv4-address | ipv6 ipv6-address } [ vpn-instance vpn-instance-name ] ] [ verbose [ tunnel tunnel-id ] ] ]

Display IKEv2 statistics.

display ikev2 statistics

Delete IKEv2 SAs and the child SAs negotiated through the IKEv2 SAs.

reset ikev2 sa [ [ { local | remote } { ipv4-address | ipv6 ipv6-address } [ vpn-instance vpn-instance-name ] ] | tunnel tunnel-id ] [ fast ]

Clear IKEv2 statistics.

reset ikev2 statistics

 

IKEv2 configuration examples

IKEv2 with pre-shared key authentication configuration example

Network requirements

As shown in Figure 11, configure an IKE-based IPsec tunnel between Switch A and Switch B to secure the communication between the switches.

·           Configure Switch A and Switch B to use the default IKEv2 proposal and the default IKEv2 policy in IKEv2 negotiation to set up IPsec SAs.

·           Configure the two switches to use the pre-shared key authentication method in IKEv2 negotiation.

Figure 11 Network diagram

 

Configuration procedures

1.      Configure Switch A:

# Assign an IP address to VLAN-interface 1.

<SwitchA> system-view

[SwitchA] interface vlan-interface 1

[SwitchA-vlan-interface1] ip address 1.1.1.1 255.255.255.0

[SwitchA-vlan-interface1] quit

# Configure IPv4 advanced ACL 3101 to identify traffic between Switch A and Switch B.

[SwitchA] acl advanced 3101

[SwitchA-acl-ipv4-adv-3101] rule 0 permit ip source 1.1.1.1 0 destination 2.2.2.2 0

[SwitchA-acl-ipv4-adv-3101] quit

# Create an IPsec transform set named tran1.

[SwitchA] ipsec transform-set tran1

# Set the packet encapsulation mode to tunnel.

[SwitchA-ipsec-transform-set-tran1] encapsulation-mode tunnel

# Use the ESP protocol for the IPsec transform set.

[SwitchA-ipsec-transform-set-tran1] protocol esp

# Specify the encryption and authentication algorithms.

[SwitchA-ipsec-transform-set-tran1] esp encryption-algorithm des-cbc

[SwitchA-ipsec-transform-set-tran1] esp authentication-algorithm sha1

[SwitchA-ipsec-transform-set-tran1] quit

# Create an IKEv2 keychain named keychain1.

[SwitchA] ikev2 keychain keychain1

# Create an IKEv2 peer named peer1.

[SwitchA-ikev2-keychain-keychain1] peer peer1

# Specify peer IP address 2.2.2.2/24.

[SwitchA-ikev2-keychain-keychain1-peer-peer1] address 2.2.2.2 24

# Specify the peer ID, which is IP address 2.2.2.2.

[SwitchA-ikev2-keychain-keychain1-peer-peer1] identity address 2.2.2.2

# Specify abcde in plain text as the pre-shared key to be used with the peer at 2.2.2.2.

[SwitchA-ikev2-keychain-keychain1-peer-peer1] pre-shared-key plaintext abcde

[SwitchA-ikev2-keychain-keychain1-peer-peer1] quit

[SwitchA-ikev2-keychain-keychain1] quit

# Create an IKEv2 profile named profile1.

[SwitchA] ikev2 profile profile1

# Specify the local authentication method as pre-shared key.

[SwitchA-ikev2-profile-profile1] authentication-method local pre-share

# Specify the remote authentication method as pre-shared key.

[SwitchA-ikev2-profile-profile1] authentication-method remote pre-share

# Specify IKEv2 keychain keychain1.

[SwitchA-ikev2-profile-profile1] keychain keychain1

# Specify the peer ID that the IKEv2 profile matches. The peer ID is IP address 2.2.2.2/24.

[SwitchA-ikev2-profile-profile1] match remote identity address 2.2.2.2 255.255.255.0

[SwitchA-ikev2-profile-profile1] quit

# Create an IKE-based IPsec policy entry. Specify the policy name as map1 and set the sequence number to 10.

[SwitchA] ipsec policy map1 10 isakmp

# Specify remote IP address 2.2.2.2 for the IPsec tunnel.

[SwitchA-ipsec-policy-isakmp-map1-10] remote-address 2.2.2.2

# Specify ACL 3101 to identify the traffic to be protected.

[SwitchA-ipsec-policy-isakmp-map1-10] security acl 3101

# Specify IPsec transform set tran1 for the IPsec policy.

[SwitchA-ipsec-policy-isakmp-map1-10] transform-set tran1

# Specify IKEv2 profile profile1 for the IPsec policy.

[SwitchA-ipsec-policy-isakmp-map1-10] ikev2-profile profile1

[SwitchA-ipsec-policy-isakmp-map1-10] quit

# Apply IPsec policy map1 to VLAN-interface 1.

[SwitchA] interface vlan-interface 1

[SwitchA-Vlan-interface1] ipsec apply policy map1

[SwitchA-Vlan-interface1] quit

2.      Configure Switch B:

# Assign an IP address to VLAN-interface 1.

<SwitchB> system-view

[SwitchB] interface Vlan-interface1

[SwitchB-Vlan-interface1] ip address 2.2.2.2 255.255.255.0

[SwitchB-Vlan-interface1] quit

# Configure IPv4 advanced ACL 3101 to identify traffic between Switch A and Switch B.

[SwitchB] acl advanced 3101

[SwitchB-acl-ipv4-adv-3101] rule 0 permit ip source 2.2.2.2 0 destination 1.1.1.0 0

[SwitchB-acl-ipv4-adv-3101] quit

# Create an IPsec transform set named tran1.

[SwitchB] ipsec transform-set tran1

# Set the packet encapsulation mode to tunnel.

[SwitchB-ipsec-transform-set-tran1] encapsulation-mode tunnel

# Use the ESP protocol for the IPsec transform set.

[SwitchB-ipsec-transform-set-tran1] protocol esp

# Specify the encryption and authentication algorithms.

[SwitchB-ipsec-transform-set-tran1] esp encryption-algorithm des-cbc

[SwitchB-ipsec-transform-set-tran1] esp authentication-algorithm sha1

[SwitchB-ipsec-transform-set-tran1] quit

# Create an IKEv2 keychain named keychain1.

[SwitchB] ikev2 keychain keychain1

# Create an IKEv2 peer named peer1.

[SwitchB-ikev2-keychain-keychain1] peer peer1

# Specify peer IP address 1.1.1.1/24.

[SwitchB-ikev2-keychain-keychain1-peer-peer1] address 1.1.1.1 24

# Specify the peer ID, which is IP address 1.1.1.1.

[SwitchB-ikev2-keychain-keychain1-peer-peer1] identity address 1.1.1.1

# Specify abcde in plain text as the pre-shared key to be used with the peer at 1.1.1.1.

[SwitchB-ikev2-keychain-keychain1-peer-peer1] pre-shared-key plaintext abcde

[SwitchB-ikev2-keychain-keychain1-peer-peer1] quit

[SwitchB-ikev2-keychain-keychain1] quit

# Create an IKEv2 profile named profile1.

[SwitchB] ikev2 profile profile1

# Specify the local authentication method as pre-shared key.

[SwitchB-ikev2-profile-profile1] authentication-method local pre-share

# Specify the remote authentication method as pre-shared key.

[SwitchB-ikev2-profile-profile1] authentication-method remote pre-share

# Specify IKEv2 keychain keychain1.

[SwitchB-ikev2-profile-profile1] keychain keychain1

# Specify the peer ID that the IKEv2 profile matches. The peer ID is IP address 1.1.1.1/24.

[SwitchB-ikev2-profile-profile1] match remote identity address 1.1.1.1 255.255.255.0

[SwitchB-ikev2-profile-profile1] quit

# Create an IKE-based IPsec policy entry. Specify the policy name as use1 and set the sequence number to 10.

[SwitchB] ipsec policy use1 10 isakmp

# Specify remote IP address 1.1.1.1 for the IPsec tunnel.

[SwitchB-ipsec-policy-isakmp-use1-10] remote-address 1.1.1.1

# Specify ACL 3101 to identify the traffic to be protected.

[SwitchB-ipsec-policy-isakmp-use1-10] security acl 3101

# Specify IPsec transform set tran1 for the IPsec policy.

[SwitchB-ipsec-policy-isakmp-use1-10] transform-set tran1

# Specify IKEv2 profile profile1 for the IPsec policy.

[SwitchB-ipsec-policy-isakmp-use1-10] ikev2-profile profile1

[SwitchB-ipsec-policy-isakmp-use1-10] quit

# Apply IPsec policy use1 to VLAN-interface 1.

[SwitchB] interface vlan-interface 1

[SwitchB-Vlan-interface1] ipsec apply policy use1

[SwitchB-Vlan-interface1] quit

Verifying the configuration

# Initiate a connection between Switch A and Switch B to trigger IKEv2 negotiation. After IPsec SAs are successfully negotiated by IKEv2, traffic between the two switches is IPsec protected.

IKEv2 with RSA signature authentication configuration example

Network requirements

As shown in Figure 12, configure an IKE-based IPsec tunnel between Switch A and Switch B to secure the communication between the switches.

Configure Switch A and Switch B to use IKEv2 negotiation and RSA signature authentication.

Figure 12 Network diagram

 

Configuration procedure

1.      Configure Switch A:

# Assign an IP address to VLAN-interface 1.

<SwitchA> system-view

[SwitchA] interface vlan-interface 1

[SwitchA-vlan-interface1] ip address 1.1.1.1 255.255.255.0

[SwitchA-vlan-interface1] quit

# Configure IPv4 advanced ACL 3101 to identify traffic between Switch A and Switch B.

[SwitchA] acl advanced 3101

[SwitchA-acl-ipv4-adv-3101] rule 0 permit ip source 1.1.1.1 0 destination 2.2.2.2 0

[SwitchA-acl-ipv4-adv-3101] quit

# Create an IPsec transform set named tran1.

[SwitchA] ipsec transform-set tran1

# Set the packet encapsulation mode to tunnel.

[SwitchA-ipsec-transform-set-tran1] encapsulation-mode tunnel

# Use the ESP protocol for the IPsec transform set.

[SwitchA-ipsec-transform-set-tran1] protocol esp

# Specify the encryption and authentication algorithms.

[SwitchA-ipsec-transform-set-tran1] esp encryption-algorithm des-cbc

[SwitchA-ipsec-transform-set-tran1] esp authentication-algorithm sha1

[SwitchA-ipsec-transform-set-tran1] quit

# Create a PKI entity named entity1.

[SwitchA] pki entity entity1

# Set the common name to switcha for the PKI entity.

[SwitchA-pki-entity-entity1] common-name switcha

[SwitchA-pki-entity-entity1] quit

# Create a PKI domain named domain1.

[SwitchA] pki domain domain1

# Set the certificate request mode to auto and set the password to 123 for certificate revocation.

[SwitchA-pki-domain-domain1] certificate request mode auto password simple 123

# Set an MD5 fingerprint for verifying the validity of the CA root certificate.

[SwitchA-pki-domain-domain1] root-certificate fingerprint md5 50c7a2d282ea710a449eede6c56b102e

# Specify the trusted CA 8088.

[SwitchA-pki-domain-domain1] ca identifier 8088

# Specify the URL of the registration server for certificate request through the SCEP protocol. This example uses http://192.168.222.1:446/eadbf9af4f2c4641e685f7a6021e7b298373feb7.

[SwitchA-pki-domain-domain1] certificate request url http://192.168.222.1:446/eadbf9af4f2c4641e685f7a6021e7b298373feb7

# Specify the CA to accept certificate requests.

[SwitchA-pki-domain-domain1] certificate request from ca

# Specify the PKI entity for certificate request as entity1.

[SwitchA-pki-domain-domain1] certificate request entity entity1

# Specify RSA key pair rsa1 with the general purpose for certificate request.

[SwitchA-pki-domain-domain1] public-key rsa general name rsa1

[SwitchA-pki-domain-domain1] quit

# Create an IKEv2 profile named profile1.

[SwitchA] ikev2 profile profile1

# Specify the local authentication method as RSA signatures.

[SwitchA-ikev2-profile-profile1] authentication-method local rsa-signature

# Specify the remote authentication method as RSA signatures.

[SwitchA-ikev2-profile-profile1] authentication-method remote rsa-signature

# Specify PKI domain domain1 for the IKEv2 profile.

[SwitchA-ikev2-profile-profile1] certificate domain domain1

# Set the local ID to FQDN name www.switcha.com.

[SwitchA-ikev2-profile-profile1] identity local fqdn www.switcha.com

# Specify the peer ID that the IKEv2 profile matches. The peer ID is FQDN name www.routerb.com.

[SwitchA-ikev2-profile-profile1] match remote identity fqdn www.routerb.com

[SwitchA-ikev2-profile-profile1] quit

# Create an IKEv2 proposal named 10.

[SwitchA] ikev2 proposal 10

# Specify the integrity protection algorithm as HMAC-MD5.

[SwitchA-ikev2-proposal-10] integrity md5

# Specify the encryption algorithm as 3DES-CBC.

[SwitchA-ikev2-proposal-10] encryption 3des-cbc

# Specify the DH group as Group 1.

[SwitchA-ikev2-proposal-10] dh group1

# Specify the PRF algorithm as HMAC-MD5.

[SwitchA-ikev2-proposal-10] prf md5

[SwitchA-ikev2-proposal-10] quit

# Create an IKEv2 policy named 1.

[SwitchA] ikev2 policy 1

# Specify IKEv2 proposal 10 for the IKEv2 policy.

[SwitchA-ikev2-policy-1] proposal 10

[SwitchA-ikev2-policy-1] quit

# Create an IKE-based IPsec policy entry. Specify the policy name as map1 and set the sequence number to 10.

[SwitchA] ipsec policy map1 10 isakmp

# Specify remote IP address 2.2.2.2 for the IPsec tunnel.

[SwitchA-ipsec-policy-isakmp-map1-10] remote-address 2.2.2.2

# Specify IPsec transform set tran1 for the IPsec policy.

[SwitchA-ipsec-policy-isakmp-map1-10] transform-set tran1

# Specify ACL 3101 to identify the traffic to be protected.

[SwitchA-ipsec-policy-isakmp-map1-10] security acl 3101

# Specify IKEv2 profile profile1 for the IPsec policy.

[SwitchA-ipsec-policy-isakmp-map1-10] ikev2-profile profile1

[SwitchA-ipsec-policy-isakmp-map1-10] quit

# Apply IPsec policy map1 to VLAN-interface 1.

[SwitchA] interface vlan-interface 1

[SwitchA-Vlan-interface1] ipsec apply policy map1

[SwitchA-Vlan-interface1] quit

2.      Configure Switch B:

# Assign an IP address to VLAN-interface 1.

<SwitchB> system-view

[SwitchB] interface Vlan-interface1

[SwitchB-Vlan-interface1] ip address 2.2.2.2 255.255.255.0

[SwitchB-Vlan-interface1] quit

# Configure IPv4 advanced ACL 3101 to identify traffic between Switch A and Switch B.

[SwitchB] acl advanced 3101

[SwitchB-acl-ipv4-adv-3101] rule 0 permit ip source 2.2.2.2 0 destination 1.1.1.0 0

[SwitchB-acl-ipv4-adv-3101] quit

# Create an IPsec transform set named tran1.

[SwitchB] ipsec transform-set tran1

# Set the packet encapsulation mode to tunnel.

[SwitchB-ipsec-transform-set-tran1] encapsulation-mode tunnel

# Use the ESP protocol for the IPsec transform set.

[SwitchB-ipsec-transform-set-tran1] protocol esp

# Specify the encryption and authentication algorithms.

[SwitchB-ipsec-transform-set-tran1] esp encryption-algorithm des-cbc

[SwitchB-ipsec-transform-set-tran1] esp authentication-algorithm sha1

[SwitchB-ipsec-transform-set-tran1] quit

# Create a PKI entity named entity2.

[SwitchB] pki entity entity2

# Set the common name to routerb for the PKI entity.

[SwitchB-pki-entity-entity2] common-name routerb

[SwitchB-pki-entity-entity2] quit

# Create a PKI domain named domain2.

[SwitchB] pki domain domain2

# Set the certificate request mode to auto and set the password to 123 for certificate revocation.

[SwitchB-pki-domain-domain2] certificate request mode auto password simple 123

# Set an MD5 fingerprint for verifying the validity of the CA root certificate.

[SwitchB-pki-domain-domain2] root-certificate fingerprint md5 50c7a2d282ea710a449eede6c56b102e

# Specify the trusted CA 8088.

[SwitchB-pki-domain-domain2] ca identifier 8088

# Specify the URL of the registration server for certificate request through the SCEP protocol. This example uses http://192.168.222.1:446/eadbf9af4f2c4641e685f7a6021e7b298373feb7.

[SwitchB-pki-domain-domain2] certificate request url http://192.168.222.1:446/eadbf9af4f2c4641e685f7a6021e7b298373feb7

# Specify the CA to accept certificate requests.

[SwitchB-pki-domain-domain2] certificate request from ca

# Specify the PKI entity for certificate request as entity2.

[SwitchB-pki-domain-domain2] certificate request entity entity2

# Specify RSA key pair rsa1 with the general purpose for certificate request.

[SwitchB-pki-domain-domain2] public-key rsa general name rsa1

[SwitchB-pki-domain-domain2] quit

# Create an IKEv2 profile named profile2.

[SwitchB] ikev2 profile profile2

# Specify the local authentication method as RSA signatures.

[SwitchB-ikev2-profile-profile2] authentication-method local rsa-signature

# Specify the remote authentication method as RSA signatures.

[SwitchB-ikev2-profile-profile2] authentication-method remote rsa-signature

# Set the local identity to FQDN name www.routerb.com.

[SwitchB-ikev2-profile-profile2] identity local fqdn www.routerb.com

# Specify the peer ID that the IKEv2 profile matches. The peer ID is FQDN name www.switcha.com.

[SwitchB-ikev2-profile-profile2] match remote identity fqdn www.switcha.com

[SwitchB-ikev2-profile-profile2] quit

# Create an IKEv2 proposal named 10.

[SwitchB] ikev2 proposal 10

# Specify the integrity protection algorithm as HMAC-MD5.

[SwitchB-ikev2-proposal-10] integrity md5

# Specify the encryption algorithm as 3DES-CBC.

[SwitchB-ikev2-proposal-10] encryption 3des-cbc

# Specify the DH group as Group 1.

[SwitchB-ikev2-proposal-10] dh group1

# Specify the PRF algorithm as HMAC-MD5.

[SwitchB-ikev2-proposal-10] prf md5

[SwitchB-ikev2-proposal-10] quit

# Create an IKEv2 policy named 1.

[SwitchB] ikev2 policy 1

# Specify IKEv2 proposal 10 for the IKEv2 policy.

[SwitchB-ikev2-policy-1] proposal 10

[SwitchB-ikev2-policy-1] quit

# Create an IPsec policy template entry. Specify the template name as template1 and set the sequence number to 1.

[SwitchB] ipsec policy-template template1 1

# Specify the remote IP address 1.1.1.1 for the IPsec tunnel.

[SwitchB-ipsec-policy-template-template1-1] remote-address 1.1.1.1

# Specify ACL 3101 to identify the traffic to be protected.

[SwitchB-ipsec-policy-template-template1-1] security acl 3101

# Specify IPsec transform set tran1 for the IPsec policy template.

[SwitchB-ipsec-policy-template-template1-1] transform-set tran1

# Specify IKEv2 profile profile2 for the IPsec policy template.

[SwitchB-ipsec-policy-template-template1-1] ikev2-profile profile2

[SwitchB-ipsec-policy-template-template1-1] quit

# Create an IKE-based IPsec policy entry by using IPsec policy template template1. Specify the policy name as use1 and set the sequence number to 1.

[SwitchB] ipsec policy use1 1 isakmp template template1

# Apply IPsec policy use1 to VLAN-interface 1.

[SwitchB] interface vlan-interface 1

[SwitchB-Vlan-interface1] ipsec apply policy use1

[SwitchB-Vlan-interface1] quit

Verifying the configuration

# Initiate a connection between Switch A and Switch B to trigger IKEv2 negotiation. After IPsec SAs are successfully negotiated by IKEv2, traffic between the two switches is IPsec protected.

Troubleshooting IKEv2

IKEv2 negotiation failed because no matching IKEv2 proposals were found

Symptom

The IKEv2 SA is in IN-NEGO status.

<Sysname> display ikev2 sa

Tunnel ID   Local                       Remote                      Status

  ---------------------------------------------------------------------------

  5           123.234.234.124/500         123.234.234.123/500         IN-NEGO

Status:

IN-NEGO: Negotiating, EST: Establish, DEL:Deleting

Analysis

Certain IKEv2 proposal settings are incorrect.

Solution

1.      Examine the IKEv2 proposal configuration to see whether the two ends have matching IKEv2 proposals.

2.      Modify the IKEv2 proposal configuration to make sure the two ends have matching IKEv2 proposals.

IPsec SA negotiation failed because no matching IPsec transform sets were found

Symptom

The display ikev2 sa command shows that the IKEv2 SA negotiation succeeded and the IKEv2 SA is in EST status. The display ipsec sa command shows that the expected IPsec SAs have not been negotiated yet.

Analysis

Certain IPsec policy settings are incorrect.

Solution

1.      Examine the IPsec configuration to see whether the two ends have matching IPsec transform sets.

2.      Modify the IPsec configuration to make sure the two ends have matching IPsec transform sets.

IPsec tunnel establishment failed

Symptom

The ACLs and IKEv2 proposals are correctly configured on both ends. The two ends cannot establish an IPsec tunnel or cannot communicate through the established IPsec tunnel.

Analysis

The IKEv2 SA or IPsec SAs on either end are lost. The reason might be that the network is unstable and the device reboots.

Solution

1.      Use the display ikev2 sa command to examine whether an IKEv2 SA exists on both ends. If the IKEv2 SA on one end is lost, delete the IKEv2 SA on the other end by using the reset ikev2 sa command and trigger new negotiation. If an IKEv2 SA exists on both ends, go to the next step.

2.      Use the display ipsec sa command to examine whether IPsec SAs exist on both ends. If the IPsec SAs on one end are lost, delete the IPsec SAs on the other end by using the reset ipsec sa command and trigger new negotiation.