Configuring IPsec· 1

Overview·· 1

Basic concepts 1

Protocols and standards 3

Implementing IPsec· 4

Configuring an ACL 4

Configuring an IPsec transform set 4

Configuring an IPsec policy· 5

Applying an IPsec policy group to an interface· 10

Displaying and maintaining IPsec· 10

Configuring IKE· 12

Overview·· 12

IKE security mechanism·· 12

IKE operation· 12

IKE functions 13

Relationship between IKE and IPsec· 14

Protocols and standards 14

Configuration task list for IKE· 14

Configuring a name for the local security gateway· 15

Configuring an IKE proposal 15

Configuring an IKE peer 16

Setting keepalive timers 18

Setting the NAT keepalive timer 19

Configuring a DPD detector 19

Disabling next payload field checking· 20

Displaying and maintaining IKE· 20

 

Overview

IP Security (IPsec) is a security framework defined by the IETF for securing IP communications. It is a Layer 3 VPN technology that transmits data in a secure tunnel established between two endpoints.

IPsec provides the following security services in insecure network environments:

·          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 overheads 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.

IPsec comprises a set of protocols, including Authentication Header (AH), Encapsulating Security Payload (ESP), Internet Key Exchange (IKE), and algorithms for authentication and encryption. AH and ESP provides security services and IKE performs automatic key exchange. For more information about IKE, see "Configuring IKE."

Basic concepts

Security protocols

IPsec comes with two security protocols:

·          AH (protocol 51)—Provides data origin authentication, data integrity, and anti-replay services by adding an AH header to each IP packet. AH is suitable only for transmitting non-critical data because it cannot prevent eavesdropping, although it can prevent data tampering. AH supports authentication algorithms such as MD5 and SHA-1.

·          ESP (protocol 50)—Provides data encryption as well as data origin authentication, data integrity, and anti-replay services by inserting an ESP header and an ESP trailer in IP packets. Unlike AH, ESP encrypts data before encapsulating the data to guarantee data confidentiality. ESP supports encryption algorithms such as DES, 3DES, and AES, and authentication algorithms such as MD5 and SHA-1. The authentication function is optional to ESP.

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. Figure 1 shows the format of IPsec packets.

Security association

A security association is an agreement negotiated between two communicating parties called IPsec peers. It comprises a set of parameters for data protection, including security protocols, encapsulation mode, authentication and encryption algorithms, and shared keys and their lifetime. SAs can be set up manually or through IKE.

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.

An SA is uniquely identified by a triplet, which consists of the security parameter index (SPI), destination IP address, and security protocol identifier (AH or ESP).

An SPI is a 32-bit number for uniquely identifying an SA. It is transmitted in the AH/ESP header. A manually configured SA requires an SPI to be specified manually for it. An IKE-created SA will have an SPI generated at random.

A manually configured SA never ages out. An IKE created SA has a specified period of 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.

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.

Encapsulation modes

IPsec supports the following IP packet encapsulation modes:

·          Tunnel mode—IPsec protects the entire IP packet, including both the IP header and the payload. It uses the entire IP packet to calculate an AH or ESP header, and then encapsulates the original IP packet and the AH or ESP header with a new IP header. If you use ESP, an ESP trailer is also encapsulated. Tunnel mode is typically used for protecting gateway-to-gateway communications.

·          Transport mode—IPsec protects only the IP payload. It uses only the IP payload to calculate the AH or ESP header, and inserts the calculated header between the original IP header and payload. If you use ESP, an ESP trailer is also encapsulated. The transport mode is typically used for protecting host-to-host or host-to-gateway communications.

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

Figure 1 Encapsulation by security protocols in different modes

 

Authentication algorithms and encryption algorithms

·          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. If the resulting digests are identical, the packet is considered intact.

IPsec supports the following hash algorithms for authentication:

?  MD5—Takes a message of arbitrary length as input and produces a 128-bit message digest.

?  SHA-1—Takes a message of a maximum length less than the 64th power of 2 in bits as input and produces a 160-bit message digest.

Compared with SHA-1, MD5 is faster but less secure.

·          Encryption algorithms:

IPsec mainly 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 plain text block with a 56-bit key. DES is the least secure but the fastest algorithm. It is sufficient for general security requirements.

?  3DES—Encrypts plain text 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 plain text data with a 128-bit, 192-bit, or 256-bit key. AES provides the highest security strength and is slower than 3DES.

IPsec SA setup modes

There are two IPsec SA setup modes:

·          Manual mode—In this mode, you manually configure and maintain all SA settings. Advanced features like periodical key update are not available. However, this mode implements IPsec independently of IKE.

·          ISAKMP mode—In this mode, IKE automatically negotiates and maintains IPsec SAs for IPsec.

If the number of IPsec tunnels in your network is small, use the manual mode. If the number of IPsec tunnels is large, use the ISAKMP mode.

IPsec tunnel

An IPsec tunnel is a bidirectional channel created between two peers. An IPsec tunnel comprises one or more pairs of SAs.

Protocols and standards

Protocols and standards relevant to IPsec are as follows:

·          RFC 2401, Security Architecture for the Internet Protocol

·          RFC 2402, IP Authentication Header

·          RFC 2406, IP Encapsulating Security Payload

·          RFC4301, Security Architecture for the Internet Protocol

·          RFC4302, IP Authentication Header

·          RFC4303, IP Encapsulating Security Payload (ESP)

Implementing IPsec

The following is the generic configuration procedure for implementing ACL-based IPsec:

1.        Configure an ACL for identifying data flows to be protected.

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

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

4.        Apply the IPsec policies to interfaces to finish IPsec configuration.

Complete the following tasks to configure ACL-based IPsec:

 

Task	Remarks
Configuring an ACL	Required. Basic IPsec configuration.
Configuring an IPsec transform set
Configuring an IPsec policy
Applying an IPsec policy group to an interface

 

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

 

Configuring an ACL

ACLs can be used to identify traffic. They are widely used in scenarios where traffic identification is desired, such as QoS and IPsec.

Configuring an IPsec transform set

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

You can configure up to 10000 IPsec transform sets in the system.

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.	transform { ah | ah-esp | esp }	Optional. ESP by default. Only when a security protocol is selected, can you configure security algorithms for it. For example, you can specify the ESP-specific security algorithms only when you select ESP as the security protocol. ESP supports three IP packet protection schemes: encryption only, authentication only, or both encryption and authentication.
4.       Specify the security algorithms.	·         Specify the encryption algorithm for ESP: esp encryption-algorithm { 3des | aes-cbc-128 | aes-cbc-192 | aes-cbc-256 | des } * ·         Specify the authentication algorithm for ESP: esp authentication-algorithm { md5 | sha1 } * ·         Specify the authentication algorithm for AH: ah authentication-algorithm { md5 | sha1 } *	Configure at least one command. By default, no security algorithm is specified.
5.       Specify the IP packet encapsulation mode for the IPsec transform set.	encapsulation-mode { transport | tunnel }	Optional. Tunnel mode by default. Transport mode applies only when the source and destination IP addresses of data flows match those of the IPsec tunnel.

 

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 using the updated parameters.

Configuring an IPsec policy

IPsec policies define which IPsec transform sets should be used to protect which data flows. An IPsec policy is uniquely identified by its name and sequence number.

IPsec policies fall into the following categories:

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

·          IPsec policy that uses IKE—The parameters are automatically negotiated through IKE.

Configuring a manual IPsec policy

To guarantee successful SA negotiations, follow these guidelines when configuring manual IPsec policies at the two ends of an IPsec tunnel:

·          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 IP address configured on the local end must be the same as the IP address of the remote end.

·          At each end, configure parameters for both the inbound SA and the outbound SA and make sure that different SAs use different SPIs.

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

Before you configure a manual IPsec policy, configure ACLs used for identifying protected traffic and configure IPsec transform sets.

To configure a manual IPsec policy:

 

Step	Command	Remarks
1.       Enter system view.	system-view	N/A
2.       Create a manual IPsec policy and enter its view.	ipsec policy policy-name seq-number manual	By default, no IPsec policy exists.
3.       Assign an ACL to the IPsec policy.	security acl acl-number	By default, an IPsec policy references no ACL. The ACL supports match criteria of the VPN attribute. An IPsec policy can reference only one ACL. If you apply multiple ACLs to an IPsec policy, only the last one takes effect.
4.       Assign an IPsec transform set to 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. To change an IPsec transform set for an IPsec policy, you must remove the reference first.
5.       Configure the local address of the IPsec tunnel	tunnel local ip-address	Not configured by default.
6.       Configure the remote address of the IPsec tunnel	tunnel remote ip-address	Not configured by default.
7.       Configure an SPI for an SA.	sa spi { inbound | outbound } { ah | esp } spi-number	By default, no SPI is configured for an SA.
8.       Configure keys for the SA.	·         Configure an authentication key in hexadecimal for AH: sa authentication-hex { inbound | outbound } ah [ cipher string-key | simple hex-key ] ·         Configure an authentication key in characters for AH: sa string-key { inbound | outbound } ah [ cipher | simple ] string-key ·         Configure a key in characters for ESP: sa string-key { inbound | outbound } esp [ cipher | simple ] string-key ·         Configure an authentication key in hexadecimal for ESP: sa authentication-hex.{ inbound | outbound } esp [ cipher string-key | simple hex-key ] ·         Configure an encryption key in hexadecimal for ESP: sa encryption-hex.{ inbound | outbound } esp [ cipher string-key | simple hex-key ]	Configure keys properly for the security protocol (AH or ESP) you have specified. If you configure a key in two modes: string and hexadecimal, only the last configured one will be used. ESP supports three IP packet protection schemes: encryption only, authentication only, or both encryption and authentication. If you configure a key in characters for ESP, the device automatically generates an authentication key and an encryption key for ESP.

 

	NOTE: You cannot change the creation mode of an IPsec policy from manual to through IKE, or vice versa. To create an IPsec policy that uses IKE, delete the manual IPsec policy, and then use IKE to configure an IPsec policy.

 

Configuring an IPsec policy that uses IKE

To configure an IPsec policy that uses IKE, 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 SA negotiation but can respond to a negotiation request. The parameters not defined in the template will be determined by the initiator. This approach applies to scenarios where the remote end's information, such as the IP address, is unknown.

Before you configure an IPsec policy that uses IKE, complete the following tasks:

·          Configure the ACLs and the IPsec transform sets for the IPsec policy.

·          To use IKEv1 negotiation, configure the IKE peer. For more information about IKE peer configuration, see "Configuring IKE."

The parameters for the local and remote ends must match.

1.        Directly configure an IPsec policy that uses IKE:

 

Step	Command	Remark
1.       Enter system view.	system-view	N/A
2.       Create an IPsec policy that uses IKE and enter its view.	ipsec policy policy-name seq-number isakmp	By default, no IPsec policy exists.
3.       Configure an IPsec connection name.	connection-name name	Optional. By default, no IPsec connection name is configured.
4.       Assign an ACL to the IPsec policy.	security acl acl-number [ aggregation | per-host ]	By default, an IPsec policy references no ACL.
5.       Assign IPsec transform sets to the IPsec policy.	transform-set transform-set-name&<1-6>	By default, an IPsec policy references no IPsec transform set.
6.       Specify an IKE peer for the IPsec policy.	ike-peer peer-name	An IPsec policy cannot reference any IKE peer that is already referenced by an IPsec profile, and vice versa.
7.       Enable and configure the perfect forward secrecy feature for the IPsec policy.	pfs { dh-group1 | dh-group2 | dh-group5 | dh-group14 }	Optional. By default, the PFS feature is not used for negotiation. For more information about PFS, see "Configuring IKE."
8.       Set the SA lifetime.	sa duration { time-based seconds | traffic-based kilobytes }	Optional. By default, the global SA lifetime is used.
9.       Enable the IPsec policy.	policy enable	Optional. Enabled by default.
10.    Return to system view.	quit	N/A
11.    Set the global SA lifetime.	ipsec sa global-duration { time-based seconds | traffic-based kilobytes }	Optional. 3600 seconds for time-based SA lifetime by default. 1843200 kilobytes for traffic-based SA lifetime by default.

 

2.        Configure an IPsec policy that uses IKE by referencing an IPsec policy template.

The parameters configurable for an IPsec policy template are the same as those you configure when directly configuring an IPsec policy that uses IKE. The difference is that more parameters are optional.

?  Required configuration: The IPsec transform sets and IKE peer.

?  Optional configuration: The ACL, PFS feature, and SA lifetime. Unlike the direct configuration, ACL configuration to be referenced by an IPsec policy is optional. The responder without ACL configuration accepts the initiator's ACL configuration.

To configure an IPsec policy that uses IKE by referencing an IPsec policy template:

 

Step	Command	Remark
1.       Enter system view.	system-view	N/A
2.       Create an IPsec policy template and enter its view.	ipsec policy-template template-name seq-number	By default, no IPsec policy template exists.
3.       Specify the ACL for the IPsec policy to reference.	security acl acl-number	Optional. By default, an IPsec policy references no ACL.
4.       Specify the IPsec transform sets for the IPsec policy to reference.	transform-set transform-set-name&<1-6>	By default, an IPsec policy references no IPsec transform set.
5.       Specify the IKE peer for the IPsec policy to reference.	ike-peer peer-name	An IPsec policy cannot reference any IKE peer that is already referenced by an IPsec profile, and vice versa.
6.       Specify the IP packet encapsulation mode.	encapsulation-mode { transport | tunnel }	Optional. Tunnel mode by default Transport mode applies only when the source and destination IP addresses of data flows match those of the IPsec tunnel.
7.       Enable and configure the perfect forward secrecy feature for the IPsec policy.	pfs { dh-group1 | dh-group2 | dh-group5 | dh-group14 }	Optional. By default, the PFS feature is not used for negotiation. For more information about PFS, see "Configuring IKE."
8.       Configure the SA lifetime.	sa duration { time-based seconds | traffic-based kilobytes }	Optional. By default, the global SA lifetime settings are used.
9.       Enable the IPsec policy.	policy enable	Optional. Enabled by default.
10.    Return to system view.	quit	N/A
11.    Configure the global SA lifetime.	ipsec sa global-duration { time-based seconds | traffic-based kilobytes }	Optional. By default, time-based SA lifetime is 3600 seconds and traffic-based SA lifetime is 1843200 kilobytes.
12.    Create an IPsec policy by referencing an IPsec policy template.	ipsec policy policy-name seq-number isakmp template template-name	By default, no IPsec policy exists.

 

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

During IKE negotiation for an IPsec policy with PFS enabled, an additional key exchange is performed. If the local end uses PFS, the remote end must also use PFS for negotiation and both ends must use the same DH group. Otherwise, the negotiation will fail.

An SA uses the global lifetime settings when it is not configured with lifetime settings in IPsec policy view. When negotiating to set up SAs, IKE uses the local lifetime settings or those proposed by the peer, whichever are smaller.

Applying an IPsec policy group to an interface

An IPsec policy group is a collection of IPsec policies with the same name but different sequence numbers. In an IPsec policy group, an IPsec policy with a smaller sequence number has a higher priority.

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

For each packet to be sent out an IPsec protected interface, the system looks through the IPsec policies in the IPsec policy group in ascending order of sequence numbers. If an IPsec policy matches the packet, the system uses the IPsec policy to protect the packet. If no match is found, the system sends the packet out without IPsec protection.

An interface can reference only one IPsec policy group. An IPsec policy that uses IKE 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 group to an interface:

 

Step	Command
1.       Enter system view.	system-view
2.       Enter interface view.	interface interface-type interface-number
3.       Apply an IPsec policy group to the interface.	ipsec policy policy-name

 

Displaying and maintaining IPsec

 

Task	Command	Remarks
Display IPsec policy information.	display ipsec policy [ brief | name policy-name [ seq-number ] ] [ | { begin | exclude | include } regular-expression ]	Available in any view.
Display IPsec policy template information.	display ipsec policy-template [ brief | name template-name [ seq-number ] ] [ | { begin | exclude | include } regular-expression ]	Available in any view.
Display IPsec transform set information.	display ipsec transform-set [ transform-set-name ] [ | { begin | exclude | include } regular-expression ]	Available in any view.
Display IPsec SA information.	display ipsec sa [ brief | policy policy-name [ seq-number ] | remote ip-address ] [ | { begin | exclude | include } regular-expression ]	Available in any view.
Display IPsec packet statistics.	display ipsec statistics [ tunnel-id integer ] [ | { begin | exclude | include } regular-expression ]	Available in any view.
Display IPsec tunnel information.	display ipsec tunnel [ | { begin | exclude | include } regular-expression ]	Available in any view.
Clear SAs.	reset ipsec sa [ parameters dest-address protocol spi | policy policy-name [ seq-number ] | remote ip-address ]	Available in user view.
Clear IPsec statistics.	reset ipsec statistics	Available in user view.

 

 

Overview

Built on a framework defined by the Internet Security Association and Key Management Protocol (ISAKMP), Internet Key Exchange (IKE) provides automatic key negotiation and SA establishment services for IPsec, simplifying the application, management, configuration and maintenance of IPsec dramatically.

Instead of transmitting keys directly across a network, IKE peers transmit keying materials between them, and calculate shared keys respectively. Even if a third party captures all exchanged data for calculating the keys, it cannot calculate the keys.

 

	NOTE: Unless otherwise specified, IKE in this chapter refers to IKEv1.

 

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.

Data authentication

Data authentication involves two concepts:

·          Identity authentication—Mutual identity authentication between peers. Two authentication methods are available: pre-shared key authentication and PKI-based digital signature authentication (RSA signature).

·          Identity protection—Encrypts the identity information with the generated keys before sending the information.

DH

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. By making sure keys have no derivative relations, it guarantees a broken key brings no threats to other keys. For IPsec, PFS is implemented by adding an additional key exchange at IKE negotiation phase 2.

IKE operation

IKE negotiates keys and establishes SAs for IPsec in two phases:

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

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

Figure 2 IKE exchange process in main mode

 

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

·          SA exchange—Used for negotiating the security policy.

·          Key exchange—Used for exchanging the DH public value and other values like the random number. Key data is generated in this stage.

·          ID and authentication data exchange—Used for identity authentication and authentication of data exchanged in phase 1.

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

IKE functions

IKE provides the following functions for IPsec:

·          Automatically negotiates IPsec parameters such as the keys.

·          Performs DH exchange when establishing an SA, making sure that each SA has a key independent of other keys.

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

·          Provides end-to-end dynamic authentication.

·          Identity authentication and management of peers influence IPsec deployment. A large-scale IPsec deployment needs the support of CAs or other institutes which manage identity data centrally.

Relationship between IKE and IPsec

Figure 3 Relationship between IKE and IPsec

 

Figure 3 illustrates the relationship between IKE and IPsec:

·          IKE is an application layer protocol using UDP and functions as the signaling protocol of IPsec.

·          IKE negotiates SAs for IPsec and delivers negotiated parameters and generated keys to IPsec.

·          IPsec uses the SAs set up through IKE negotiation for encryption and authentication of IP packets.

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

Configuration task list for IKE

Determine the following parameters prior to IKE configuration:

·          The strength of the algorithms for IKE negotiation (the security protection level), including the identity authentication method, encryption algorithm, authentication algorithm, and DH group. Different algorithms provide different levels of protection. A stronger algorithm means more resistance to decryption of protected data but requires more resources. Generally, the longer the key, the stronger the algorithm.

·          The pre-shared key or the PKI domain the certificate belongs to. For more information about PKI configuration, see "Configuring PKI."

To configure IKE:

 

Task	Remarks
Configuring a name for the local security gateway	Optional.
Configuring an IKE proposal	Optional. Required if you want to specify an IKE proposal for an IKE peer to reference.
Configuring an IKE peer	Required.
Setting keepalive timers	Optional.
Setting the NAT keepalive timer	Optional.
Configuring a DPD detector	Optional.
Disabling next payload field checking	Optional.

 

Configuring a name for the local security gateway

If the IKE negotiation peer uses the security gateway name as its ID to initiate IKE negotiation (the id-type name or id-type user-fqdn command is configured on the initiator), configure the ike local-name command in system view or the local-name command in IKE peer view on the local device. If you configure both commands, the name configured by in IKE peer view is used.

To configure a name for the local security gateway:

 

Step	Command	Remarks
1.       Enter system view.	system-view	N/A
2.       Configure a name for the local security gateway.	ike local-name name	Optional. By default, the device name is used as the name of the local security gateway.

 

Configuring an IKE proposal

An IKE proposal defines a set of attributes describing how IKE negotiation should take place. You may create multiple IKE proposals with different preferences. The preference of an IKE proposal is represented by its sequence number. The lower the sequence number, the higher the preference.

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, and the peer searches its own IKE proposals for a match. The search starts from the IKE proposal with the lowest sequence number and proceeds in the ascending order of sequence number until a match is found or all the IKE proposals are found mismatching. The matching IKE proposals are used to establish the secure tunnel.

The two matching IKE proposals have the same encryption algorithm, authentication method, authentication algorithm, and DH group. The SA lifetime takes the SA lifetime with a smaller value of the two.

By default, there is an IKE proposal, which has the lowest preference and uses the default encryption algorithm, authentication method, authentication algorithm, DH group, and ISAKMP SA lifetime.

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	N/A
3.       Specify an encryption algorithm for the IKE proposal.	encryption-algorithm { aes-cbc [ key-length ] | des-cbc }	Optional. 56-bit DES by default.
4.       Specify an authentication method for the IKE proposal.	authentication-method { pre-share | rsa-signature }	Optional. Pre-shared key by default.
5.       Specify an authentication algorithm for the IKE proposal.	authentication-algorithm { md5 | sha | sha256 }	Optional. SHA1 by default.
6.       Specify a DH group for key negotiation in phase 1.	dh { group1 | group2 | group5 | group14 }	Optional. The default DH group is group1 (the 768-bit DH group).
7.       Set the ISAKMP SA lifetime for the IKE proposal.	sa duration seconds	Optional. 86400 seconds by default. Before an ISAKMP SA expires, IKE negotiates a new SA to replace it. DH calculation in IKE negotiation takes time, especially on low-end devices. To prevent SA updates from influencing normal communication, set the lifetime greater than 10 minutes.

 

Configuring an IKE peer

For an IPsec policy that uses IKE, you must configure an IKE peer by performing the following tasks:

·          Specify the IKE negotiation mode for the local end to use in IKE negotiation phase 1. If the IP address of the remote end is obtained dynamically and pre-shared key authentication is used, H3C recommends setting the IKE negotiation mode of the local end to aggressive. When acting as the IKE negotiation responder, the local end uses the IKE negotiation mode of the remote end.

·          Specify the IKE proposals for the local end to use when acting as the IKE negotiation initiator. When acting as the responder, the local end uses the IKE proposals configured in system view for negotiation.

·          Configure a pre-shared key for pre-shared key authentication or a PKI domain for digital signature authentication.

·          Specify the ID type for the local end to use in IKE negotiation phase 1. With pre-shared key authentication, the ID type must be IP address for main mode IKE negotiation and can be IP address, FQDN, or user FQDN for aggressive mode IKE negotiation.

·          Specify the name or IP address of the local security gateway. You perform this task only when you want to specify a special address, a loopback interface address, for example, as the local security gateway address.

·          Specify the name or IP address of the remote security gateway. For the local end to initiate IKE negotiation, you must specify the name or IP address of the remote security gateway on the local end so the local end can find the remote end.

·          Enable NAT traversal. If there is NAT gateway on the path for tunneling, you must configure NAT traversal at the two ends of the IPsec tunnel, because one end may use a public address while the other end uses a private address.

·          Specify the DPD detector for the IKE peer.

To configure an IKE peer:

 

Step	Command	Remarks
1.       Enter system view.	system-view	N/A
2.       Create an IKE peer and enter IKE peer view.	ike peer peer-name	N/A
3.       Specify the IKE negotiation mode for phase 1.	exchange-mode { aggressive | main }	Optional. The default is main.
4.       Specify the IKE proposals for the IKE peer to reference.	proposal proposal-number&<1-6>	Optional. By default, an IKE peer references no IKE proposals, and, when initiating IKE negotiation, it uses the IKE proposals configured in system view. If the IKE negotiation mode in phase 1 is aggressive, only the first IKE proposal specified for the IKE peer takes effect.
5.       Configure a pre-shared key for pre-shared key authentication or specify a PKI domain for digital signature authentication.	·         To configure a pre-shared key: pre-shared-key [ cipher | simple ] key ·         To specify a PKI domain: certificate domain domain-name	Configure either command according to the authentication method for the IKE proposal.
6.       Select the ID type for IKE negotiation phase 1.	id-type { ip | name | user-fqdn }	Optional. By default, the ID type is IP.
7.       Configure a name for the local security gateway.	local-name name	Optional. By default, no name is configured for the local security gateway in IKE peer view, and the security gateway name configured by using the ike local-name command is used.
8.       Specify the name of the remote security gateway.	remote-name name	Optional. The remote gateway name configured with remote-name command on the local gateway must be identical to the local name configured with the local-name command on the peer.
9.       Configure an IP address for the local gateway.	local-address ip-address	Optional. By default, it is the primary IP address of the interface referencing the security policy.
10.    Specify the IP addresses of the remote gateway.	remote-address { hostname [ dynamic ] | low-ip-address [ high-ip-address ] }	Optional. The remote IP address configured with the remote-address command on the local gateway must be identical to the local IP address configured with the local-address command on the peer.
11.    Enable the NAT traversal function for IPsec/IKE.	nat traversal	Optional. Required when a NAT gateway is present in the VPN tunnel constructed by IPsec/IKE. Disabled by default.
12.    Set the subnet types of the two ends.	·         Set the subnet type of the local end: local { multi-subnet | single-subnet } ·         Set the subnet type of the peer end: peer { multi-subnet | single-subnet }	Optional. The default subnet type is single-subnet. Use these two commands only when the device is working together with a NetScreen device.
13.    Apply a DPD detector to the IKE peer.	dpd dpd-name	Optional. No DPD detector is applied to an IKE peer by default. For more information about DPD configuration, see "Configuring a DPD detector."

 

	NOTE: After modifying the configuration of an IPsec IKE peer, execute the reset ipsec sa and reset ike sa commands to clear existing IPsec and IKE SAs. Otherwise, SA re-negotiation will fail.

 

Setting keepalive timers

IKE maintains the link status of an ISAKMP SA by keepalive packets. Generally, if the peer is configured with the keepalive timeout, you must configure the keepalive packet transmission interval on the local end. If the peer receives no keepalive packet during the timeout interval, the ISAKMP SA is tagged with the TIMEOUT tag (if it does not have the tag), or deleted along with the IPsec SAs it negotiated (when it has the tag already).

The keepalive timeout configured at the local end must be longer than the keepalive interval configured at the remote end. Since it seldom occurs that more than three consecutive packets are lost on a network, the keepalive timeout can be configured to be three times of the keepalive interval.

To set the keepalive timers:

 

Step	Command	Remarks
1.       Enter system view.	system-view	N/A
2.       Set the ISAKMP SA keepalive interval.	ike sa keepalive-timer interval seconds	No keepalive packet is sent by default.
3.       Set the ISAKMP SA keepalive timeout.	ike sa keepalive-timer timeout seconds	No keepalive packet is sent by default.

 

Setting the NAT keepalive timer

If IPsec traffic needs to pass through NAT security gateways, you must configure the NAT traversal function. If no packet travels across an IPsec tunnel in a certain period of time, the NAT mapping may get aged and be deleted, disabling the tunnel beyond the NAT gateway from transmitting data to the intended end. To prevent NAT mappings from being aged, an ISAKMP SA behind the NAT security gateway sends NAT keepalive packets to its peer at a certain interval to keep the NAT session alive.

To set the NAT keepalive timer:

 

Step	Command	Remarks
1.       Enter system view.	system-view	N/A
2.       Set the NAT keepalive interval.	ike sa nat-keepalive-timer interval seconds	20 seconds by default.

 

Configuring a DPD detector

DPD irregularly detects dead IKE peers. It works as follows:

1.        When the local end sends an IPsec packet, it checks the time the last IPsec packet was received from the peer.

2.        If the time interval exceeds the DPD interval, it sends a DPD hello to the peer.

3.        If the local end receives no DPD acknowledgement within the DPD packet retransmission interval, it retransmits the DPD hello.

4.        If the local end still receives no DPD acknowledgement after having made the maximum number of retransmission attempts (two by default), it considers the peer already dead, and clears the IKE SA and the IPsec SAs based on the IKE SA.

DPD enables an IKE entity to check the liveliness of its peer only when necessary. It generates less traffic than the keepalive mechanism, which exchanges messages periodically.

To configure a DPD detector:

 

Step	Command	Remarks
1.       Enter system view.	system-view	N/A
2.       Create a DPD detector and enter its view.	ike dpd dpd-name	N/A
3.       Set the DPD interval.	interval-time interval-time	Optional. 10 seconds by default.
4.       Set the DPD packet retransmission interval.	time-out time-out	Optional. 5 seconds by default.

 

Disabling next payload field checking

The Next payload field is in the generic payload header of the last payload of the IKE negotiation message (the message comprises multiple payloads). According to the protocol, this field must be 0 if the payload is the last payload of the packet. However, it may be set to other values on some brands of devices. For interoperability, disable the checking of this field.

To disable Next payload field checking:

 

Step	Command	Remark
1.       Enter system view.	system-view	N/A
2.       Disable Next payload field checking.	ike next-payload check disabled	Enabled by default.

 

Displaying and maintaining IKE

 

Task	Command	Remarks
Display IKE DPD information.	display ike dpd [ dpd-name ] [ | { begin | exclude | include } regular-expression ]	Available in any view.
Display IKE peer information.	display ike peer [ peer-name ] [ | { begin | exclude | include } regular-expression ]	Available in any view.
Display IKE SA information.	display ike sa [ verbose [ connection-id connection-id | remote-address remote-address ] ] [ | { begin | exclude | include } regular-expression ]	Available in any view.
Display IKE proposal information.	display ike proposal  [ | { begin | exclude | include } regular-expression ]	Available in any view.
Clear SAs established by IKE.	reset ike sa [ connection-id ]	Available in user view.