This help contains the following topics:

·     Introduction

¡     Security protocols and encapsulation modes

¡     Authentication and encryption

¡     IPsec SA

¡     IKE negotiation

¡     IPsec tunnel establishment

¡     IPsec smart link selection

·     Restrictions and guidelines

Introduction

IP Security (IPsec) is defined by the IETF to provide interoperable, high-quality, cryptography-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.

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 defines the encapsulation of the AH header in an IP packet. 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.

·     ESP defines the encapsulation of the ESP header and trailer in an IP packet. 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.

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

·     Tunnel mode

The security protocols protect the entire IP packet. 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

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. IPsec supports the following types of authentication algorithms:

·     Hash-based Message Authentication Code (HMAC) based authentication algorithms, including HMAC-MD5 and HMAC-SHA.

HMAC-MD5 is faster but less secure than HMAC-SHA.

·     SM3 authentication algorithms.

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.

·     SM—Encrypts plaintext data with a 128-bit key. SM provides the same level of security strength as AES.

IPsec SA

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

·     Security protocols.

·     Encapsulation mode.

·     Authentication algorithm.

·     Encryption algorithm.

·     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. It is transmitted in the AH/ESP header.

An IKE-created SA has a lifetime and will be deleted when its time-based or traffic-based lifetime timer expires. Before the SA lifetime timer expires, IKE negotiates a new SA, which takes over immediately after its creation.

IKE negotiation

IKE negotiates SAs for IPsec and transfers the SAs to IPsec, and IPsec uses the SAs to protect IP packets. 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.

Phase 1 negotiation can use the main mode, aggressive mode, or GM main mode. The aggressive mode is faster than the main mode but it does not provide identity information protection. The main mode provides identity information protection but is slower. Choose the appropriate negotiation mode according to your requirements. The GM main mode must be used if the local IKE peer uses the RSA-DE or SM2-DE digital envelop authentication method.

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

IPsec tunnel establishment

Two peers establish an IPsec tunnel in between by applying an IPsec policy to an interface. An IPsec policy defines the range of packets to be protected by IPsec and the security parameters used for the protection.

When an IPsec peer identifies the packets to be protected according to the security policy, it sets up an IPsec tunnel and sends the packet to the remote peer through the tunnel. The IPsec tunnel 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 sending a packet, an interface configured with IPsec policies looks through the IPsec policies in ascending order of policy priorities. If the packet matches a protected flow of an IPsec policy, the interface encapsulates the packet according to the IPsec policy. If no match is found, the interface sends the packet out without IPsec protection.

·     When the interface receives an IPsec packet destined for the local device, it searches for the inbound IPsec SA according to the SPI in the IPsec packet header for de-encapsulation. If the de-encapsulated packet matches a protected data flow, the device processes the packet. If the de-encapsulated packet does not match a protected data flow, the device drops the packet.

In an IPsec policy, you can specify whether to protect a data flow by selecting the action (Protect or Do not protect). You can define multiple data flows in an IPsec policy. The device processes a packet according to the action defined in the first matching data flow of the packet.

·     Both inbound and outbound packets of an interface need to match the data flows defined in the IPsec policy. The device performs forward matching of the data flows for outbound packets and backward matching of the data flows for inbound packets.

·     In outbound direction, packets that match "protect" data flows will be protected by IPsec. Packets that match no data flows or match "unprotect" data flows will not be protected by IPsec.

·     In inbound direction, non-IPsec packets that match "protect" data flows will be dropped. IPsec packets destined for the local device will be de-encapsulated.

IPsec smart link selection

To improve network stability and availability, multiple links are typically deployed at the network egress to connect to the destination network. The qualities of these links (in terms of packet loss ratio and delay) are not static but keep changing with time. It is important that the gateway device can dynamically select a link with desired transmission quality to establish the IPsec tunnel to the destination. IPsec smart link selection can meet this requirement.

IPsec smart link selection enables the gateway to monitor the real-time packet loss ratio and delay of the active link over which the IPsec tunnel is established. If the packet loss ratio or delay of the link exceeds the specified threshold, IPsec smart link selection reselects a link for the IPsec tunnel. You can also manually activate a link to establish the IPsec tunnel over that link.

IPsec smart link selection provides the following benefits:

·     Avoid the condition that some links are busy and some links are idle when multiple links are deployed at the network egress for load balancing.

·     Select proper links for customers when they cannot select links by themselves.

·     Avoid forwarding traffic to a failed link between the network egress device and the destination device.

Restrictions and guidelines

·     When you specify the remote host name in an IPsec policy, follow these restrictions and guidelines:

¡     If the remote host name is resolved by a DNS server, the local device gets the latest IP address corresponding to the host name by sending a query to the DNS server when the cached DNS entry ages. The DNS entry aging information is obtained from the DNS server.

¡     If the remote host name is resolved by a locally configured static DNS entry and the IP address in the entry is changed, you must respecify the remote host name in the IPsec policy to get the new IP address.

·     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. If the ACL rules on IPsec peers do not form mirror images of each other, SAs can be set up only when both of the following requirements are met:

¡     The range specified by an ACL rule on one peer is covered by its counterpart ACL rule on the other peer.

¡     The peer with the narrower rule initiates SA negotiation.

If a wider ACL rule is used by the SA initiator, the negotiation request might be rejected because the matching traffic is beyond the scope of the responder.

·     If you do not configure the local identity in an IPsec policy, the policy uses the global local identity settings configured in the advanced settings.

·     Modifications to the following settings in an IPsec policy take effect only on IPsec SAs set up after the modifications:

¡     Encapsulation mode.

¡     Security protocol.

¡     Security algorithms.

¡     PFS.

¡     IPsec SA lifetimes.

¡     IPsec SA idle timeout.

For the modifications to take effect on existing IPsec SAs, you must reset the IPsec SAs.

·     The IPsec peers of an IPsec tunnel must have IPsec policies that use the same security protocols, security algorithms, and encapsulation mode.

·     When IKE negotiates IPsec SAs, it uses the IPsec SA lifetime settings configured in the IPsec policy to negotiate the IPsec SA lifetime with the peer. If the IPsec SA lifetime settings are not configured in the IPsec policy, the global IPsec SA lifetime settings are used. IKE uses the local lifetime settings or those proposed by the peer, whichever are smaller.

·     If a link used by smart link selection uses the gateway address as the next hop address, you must manually change the link next hop address whenever the gateway address is changed.