The IKE Phase 2 proposals for negotiating security parameters

Similar to Phase 1 negotiations, the purpose of IKE Phase 2 is to negotiate another set of encryption and authentication algorithms, and the correspondent secret keys, so that the established IPSec SA provides protection to subsequent IPSec VPN communications.

IKE Phase 2 negotiations determine:

• Which encryption algorithms may be applied to provide data confidentiality for IP Encapsulating Security Payload

(ESP) l Which authentication hash may be used for data integrity, authentication and anti-replay creating in IP

Encapsulating Security Payload (ESP) l Whether PFS is applied to generate a secret session key or not

• Which Diffie-Hellman group (DH Group) will be used to generate a secret session key if PFS is applied

FortiWAN IKE Phase 2 supports multiple proposals of encryption and authentication algorithms. However, a successful IKE Phase 2 proposal negotiation requires partially matched proposals on the both units. Incompatible IKE proposals fails the IKE Phase 2 negotiations. Please make sure on this while configuring.

Similar to the processes in Phase 1, two FortiWAN units handle the negotiations of encryption and authentication algorithms according to their IKE proposals. The only thing that is different from Phase 1 is Perfect Forward Secrecy (PFS).

Perfect Forward Secrecy (PFS)

By default, the standard IKE Phase 2 derives the secret session key (for IPSec Security Association) based on the secret session key of ISAKMP Security Association (outcome of Phase 1 negotiations) without additional private materials. The secret session keys of IPSec SA might become vulnerable (to be recovered) if the keys of ISAKMP SA are broken or compromised. Perfect Forward Secrecy (PFS) is the option for IKE Phase 2 to force a new DiffieHellman exchange (it implies a new private key material) involved in the calculations of secret session keys, so that they are unrelated to only the Phase 1 keys (can not be recovered with only the compromised ISAKMP SA secret key). Therefore, a DH Group has to be specified for a IKE Phase 2 proposal if the PFS is applied to it. Certainly, PFS gives securer IPSec SA secret key, but more time is spent on the calculations.

Quick mode selector

Quick mode selector is a rule to determine which packet is transferred throuth IPSec VPN, according to the source IP address, source port, destination IP address, destination port and protocol of a packet. For Tunnel Mode, it usually implies the hosts (or a network) behind the two FortiWAN units trying to communicate to each other through the IPSec VPN tunnel established between the two FortiWAN. Make sure the Quick mode selector of one endpoint is correspondent to the opposite endpoint. A source IP address defined in the selector in one peer must be defined as the destination IP address of the selector of the opposite peer, and vice versa. FortiWAN supports only Tunnel Routing (TR) traffic to be transferred through IPSec VPN in Transport Mode, therefore, the quick mode selector is not required for Phase 2 configurations of Transport Mode.

IKE Phase 2 Web UI fields:

IKE Phase 1 and Phase 2 are both the necessaries to establish an IPSec VPN, thus configurations of an IPSec VPN must contains configurations of the two Phases. Choosing a set of Phase 1 parameters that you would like to define the correspondent Phase 2 parameters for. The Phase 2 configuration panel is below the Phase 1 panel on the Web UI. Click the add button on the header of Phase 2 or the add button of an existing Phase 2 configuration to add a new Phase 2 configuration panel.

For IPSec Tunnel mode, you can define multiple sets of Phase 2 parameters within one Phase 1 configuration for different Phase 2 Quick Mode selectors. A Phase 2 configuration contains only one quick mode selector used to filter packets matching the only one pair of packet source, destination and protocol. To allow different traffic (for example, traffic of different protocol) to be transferred through the same IPSec VPN tunnel (through the same Local and Remote IPs), it requires multiple Phase 2 configurations (different quick mode selectors) to associate with the same Phase 1. Moreover, you can deliver different IKE Phase 2 proposals (different encryption, authentication algorithms and DH groups) to the multiple quick mode selectors, if multiple security levels are necessary.

For IPSec Transport mode, the Phase 2 configuration does not require a Quick Mode selector. FortiWAN’s IPSec Transport mode is designed to protect only communications of Tunnel Routing. Tunnel Routing takes the part to evaluate packets for TR transmission (TR rules) and distributes packets over TR tunnels (TR algorithms), then IPSec Transport mode established on a TR tunnel (Local IP and Remote IP) protects all the passing TR packets. Therefore, multiple Phase 2 sets within a Phase 1 is not required for Transport mode. Remember that FortiWAN supports only two kinds of site-to-site IPSec VPN, “IPSec Tunnel mode” and “Tunnel Routing over IPSec Transport mode”.

Add / Delete / Move-Up / Move-Down	l	The buttons for: Adding a new configuration panel below current Phase 2 configuration
	l	Deleting the current Phase 2 configuration
	l	Moving the current Phase 2 configuration up a row
	l	Moving the current Phase 2 configuration down a row The buttons for Phase 2 configurations are only available for IPSec Tunnel mode. Each Phase 1 configuration of Transport mode contains one and only one Phase 2 configuration. Packets that matching a Quick Mode selector are allowed to pass through the correspondent IPSec VPN. However, each Quick Mode selector is required to be incompatible with the others, Phase 2 configurations moving-up or moving-down is nothing about rule first-match.
Name		A “unique” description name for the Phase 2 definition. The maximum length is “?” characters. The name is not a parameter exchanged with the opposite unit during Phase 2 negotiations. This name can contain a piece of information used for simple management, such as it can reflect where the correspondent remote unit is or what the purpose it is. It is also the index used in IPSec Statistics (See “Statistics > IPSec”).

 

Hide Details / Show Details

Click to expand or collapse the configuration details.

 

 

 

Proposal

An IKE phase 2 proposal is a combination of one or multiple encryption algorithms, one or multiple authentication algorithms, one strength of DH key exchange if PFS is enabled, and the key lifetime. Select the encryption and authentication algorithms, strength of DH key exchange, and the key lifetime for the IKE phase 2 proposal that will be used in the IKE Phase 2 negotiations. Make sure the Phase 2 proposals of the both units performing the Phase 2 negotiations are compatible. Incompatible proposals cause Phase 2 negotiations going to failure.

 

 

 

	Encryption		Select one or multiple of the following symmetric-key encryption algorithms:
		l	NULL: NULL means perform an integrity check only; packets are not encrypted. It is invalid to set both Encryption and Authentication to null.
		l	DES: Digital Encryption Standard, a 64-bit block algorithm that uses a 56-bit key.
		l	3DES: Triple-DES; plain text is encrypted three times by three keys.
		l	AES128: A 128-bit block algorithm that uses a 128-bit key.
		l	AES192: A 128-bit block algorithm that uses a 192-bit key.
		l	AES256: A 128-bit block algorithm that uses a 256-bit key. The remote peer or client must be configured to use at least one of the encryption proposals that you define. Note that AES128, AES192 and AES256 will be suggested for better performance.

 

 

 

Authentication	Select one multiple of the following authentication algorithms:
l	NULL: NULL means perform an message encryption only; ESP Auth is not calculated. It is invalid to set both Encryption and Authentication to null.
l	MD5: A MD5-based MAC algorithm (hmac-md5) with 128-bit message digest.
l	SHA1: A SHA1-based MAC algorithm (hmac-sha1) with 160-bit message digest.
l	SHA256: A SHA256-based MAC algorithm (hmac-sha256) with 256bit message digest.
l	SHA384: A SHA384-based MAC algorithm (hmac-sha384) with 384bit message digest.
l	SHA512: A SHA512-based MAC algorithm (hmac-sha512) with 512bit message digest. The remote peer or client must be configured to use at least one of the authentication proposals that you define.

 

 

 

	PFS Group		As the previous descriptions, PFS is an option to involve a new Diffie-Hellman exchange in the calculation of secret session key during Phase 2. Thus, you have to specify the DiffieHellman group for the new Diffie-Hellman exchange if PFS is enable. To apply PFS to the Phase 2 key calculation, you just need to select one of the PFS groups 1, 2, 5, and 14 for Diffie-Hellman group. A PFS group implies a Diffie-Hellman (DH) group actually, which determines the strength of the private key material used in the Diffie-Hellman key exchange process. A higher group number implies a securer key against private key recover attacks, but additional processing time for the key calculation is required. To apply no PFS to the Phase 2 key calculation, just make all the PFS Group options unchecked.
		l	PFS Group 1: Enable PFS with DH Group 1, 768-bit group
		l	PFS Group 2: Enable PFS with DH Group 2, 1024-bit group
		l	PFS Group 5: Enable PFS with DH Group 5, 1536-bit group
		l	PFS Group 14: Enable PFS with DH Group 14, 2048-bit group

 

 

	Keylife	Enter the time interval (in seconds) that the negotiated secret keys (used for IPSec SA) are valid during. For the expiration of keys, IKE Phase 2 is performed automatically to negotiate new keys without interrupting normal IPSec VPN communications. Keylife of IPSec SA’s secret keys is suggested to be shorter than the keylife of ISAKMP SA’s secret keys.
	Quick Mode	Configurations of Quick Mode is required only for IPSec Tunnel Mode. A Quick Mode selector determines the acceptance or rejection of transmission through the IPSec VPN tunnel for packets. It usually implies the IPSec VPN communications between private networks (hosts) behind the two FortiWANs unit (IPsec VPN gateways). Packets coming form the networks behind the local FortiWAN and going to another network behind the remote FortiWAN are evaluated by Quick Mode selectors at the local FortiWAN unit. Only packets matching the selector are allowed to be transferred via the IPSec VPN tunnel. A Quick Mode selector consists of the following five filters:
	l	Source: the source of a packet that is allowed to be transferred via the IPSec VPN tunnel. It can be an IPv4 address or an IPv4 subnet behind the local FortiWAN.
	l	Source Port: the source port of a packet that is allowed to be transferred via the IPSec VPN tunnel.
	l	Destination : the destination of a packet that is allowed to be transferred via the IPSec VPN tunnel. It can be an IPv4 address or an IPv4 subnet behind the remote FortiWAN.
	l	Destination Port: the destination port of a packet that is allowed to be transferred via the IPSec VPN tunnel.
	l	Protocol: the protocol of a packet that is allowed to be transferred via the IPSec VPN tunnel. Note that one pair of source and destination is not allowed to be set to multiple Quick Mode selectors, neither a subset of the pair is. Make sure the pair of source and destination defined in a Quick Mode selector is absolutely incompatible to other Quick Mode selectors (no matter which Phase 1 configuration they belong to, current one or others). It’s necessary to have an Auto Routing (AR) filter that is correspondent with the Quick Mode selector you made, see the following section “Define routing policies for an IPSec VPN”.

So far, we have introduced the concept of IPSec VPN and how to configure the settings of FortiWAN’s IPSec. However, the success of the IPSec VPN establishment and communications actually requires the cooperation between FortiWAN’ IPSec and other functions, Auto Routing, NAT and Tunnel Routing. In other words, besides the configurations of IPSec, correspondent policies of Auto Routing, NAT or Tunnel Routing are required to set up an IPSec VPN. See “Define routing policies for IPSec VPN”.