IPsec & IKE

In This Section:

Overview

In symmetric cryptographic systems, both communicating parties use the same key for encryption and decryption. The material used to build these keys must be exchanged in a secure fashion. Information can be securely exchanged only if the key belongs exclusively to the communicating parties.

The goal of the Internet Key Exchange (IKE) is for both sides to independently produce the same symmetrical key. This key then encrypts and decrypts the regular IP packets used in the bulk transfer of data between VPN peers. IKE builds the VPN tunnel by authenticating both sides and reaching an agreement on methods of encryption and integrity. The outcome of an IKE negotiation is a Security Association (SA).

This agreement upon keys and methods of encryption must also be performed securely. For this reason, IKE is composed of two phases. The first phase lays the foundations for the second. Both IKEv1 and IKEv2 are supported in Security Gateways of version R71 and higher.

Diffie-Hellman (DH) is that part of the IKE protocol used for exchanging the material from which the symmetrical keys are built. The Diffie-Hellman algorithm builds an encryption key known as a "shared secret" from the private key of one party and the public key of the other. Since the IPsec symmetrical keys are derived from this DH key shared between the peers, at no point are symmetric keys actually exchanged.

IKE Phase I

During IKE Phase I:

The peers authenticate, either by certificates or via a pre-shared secret. (More authentication methods are available when one of the peers is a remote access client.)
A Diffie-Hellman key is created. The nature of the Diffie-Hellman protocol means that both sides can independently create the shared secret, a key which is known only to the peers.
Key material (random bits and other mathematical data) as well as an agreement on methods for IKE phase II are exchanged between the peers.

In terms of performance, the generation of the Diffie-Hellman Key is slow and heavy. The outcome of this phase is the IKE SA, an agreement on keys and methods for IKE phase II. Figure below illustrates the process that takes place during IKE phase I.

Note - The exact negotiation stages differ between IKEv1 and IKEv2.

IKE Phase II (Quick mode or IPSec Phase)

IKE phase II is encrypted according to the keys and methods agreed upon in IKE phase I. The key material exchanged during IKE phase II is used for building the IPsec keys. The outcome of phase II is the IPsec Security Association. The IPsec SA is an agreement on keys and methods for IPsec, thus IPsec takes place according to the keys and methods agreed upon in IKE phase II.

After the IPsec keys are created, bulk data transfer takes place:

IKEv1 and IKEv2

IKEv2 is supported inside VPN communities working in Simplified mode.

IKEv2 is configured in the VPN Community Properties window > Encryption. The default setting is IKEv1 only. IKEv2 is automatically always used for IPv6 traffic. The encryption method configuration applies to IPv4 traffic only.

For Remote users, the IKE settings are configured in Global Properties > Remote Access > VPN Authentication and Encryption. IKEv2 is not supported for Remote Access.

Note - IKEv2 is not supported on UTM-1 Edge devices or VSX objects before R75.40VS. If UTM-1 Edge devices or such VSX objects are included in a VPN Community, the Encryption setting should be Support IKEv1.

Methods of Encryption and Integrity

Two parameters are decided during the negotiation:

Encryption algorithm

Hash algorithm

Parameter	IKE Phase 1 (IKE SA)	IKE PHASE 2 (IPSec SA)
Encryption	AES-128 AES-256(default) 3DES DES CAST (IKEv1 only)	AES-128 (default) AES-256 3DES DES DES-40CP (IKEv1 only) CAST (IKEv1 only) CAST-40 (IKEv1 only) NULL AES-GCM-128 AES-GCM-256
Integrity	MD5 SHA1 (default) SHA -256 AES-XCBC SHA -384	MD5 SHA1 (default) SHA -256 AES-XCBC SHA -384

NULL means perform an integrity check only; packets are not encrypted.

Diffie Hellman Groups

The Diffie-Hellman key computation (also known as exponential key agreement) is based on the Diffie Hellman (DH) mathematical groups. A Security Gateway supports these DH groups during the two phases of IKE.

Parameter	IKE Phase 1 (IKE SA)	IKE Phase 2 (IPSec SA)
Diffie Hellman Groups	Group2 (1024 bits) (default) Group1 (768 bits) Group5 (1536 bits) Group14 (2048 bits) Group19 (256-bit ECP) Group20 (384-bit ECP)	Group2 (1024 bits) (default) Group1 (768 bits) Group5 (1536 bits) Group14 (2048 bits) Group19 (256-bit ECP) Group20 (384-bit ECP)

A group with more bits ensures a key that is harder to break, but carries a heavy cost in terms of performance, since the computation requires more CPU cycles.

Phase I modes

Between Security Gateways, there are two modes for IKE phase I. These modes only apply to IKEv1:

Main Mode
Aggressive Mode

If aggressive mode is not selected, the Security Gateway defaults to main mode, performing the IKE negotiation using six packets; aggressive mode performs the IKE negotiation with three packets.

Main mode is preferred because:

Main mode is partially encrypted, from the point at which the shared DH key is known to both peers.
Main mode is less susceptible to Denial of Service (DoS) attacks. In main mode, the DH computation is performed after authentication. In aggressive mode, the DH computation is performed parallel to authentication. A peer that is not yet authenticated can force processor intensive Diffie-Hellman computations on the other peer.
Note - Use aggressive mode when a Check Point Security Gateway needs to negotiate with third party VPN solutions that do not support main mode.

When dealing with remote access, IKE has additional modes:

Hybrid mode. Hybrid mode provides an alternative to IKE phase I, where the Security Gateway is allowed to authenticate using certificates and the client via some other means, such as SecurID. For more information on Hybrid mode, see the R80.10 Remote Access VPN Administration Guide.
Office mode. Office mode is an extension to the IKE protocol. Office Mode is used to resolve routing issues between remote access clients and the VPN domain. During the IKE negotiation, a special mode called config mode is inserted between phases I and II. During config mode, the remote access client requests an IP address from the Security Gateway. After the Security Gateway assigns the IP address, the client creates a virtual adapter in the Operating System. The virtual adapter uses the assigned IP address. For more information, see the R80.10 Remote Access VPN Administration Guide.

Renegotiating IKE & IPsec Lifetimes

IKE phase I is more processor intensive than IKE phase II, because the Diffie-Hellman keys have to be produced, and the peers authenticated, each time. For this reason, IKE phase I is performed less frequently. However, the IKE SA is only valid for a certain period, after which the IKE SA must be renegotiated. The IPsec SA is valid for an even shorter period, meaning many IKE phase II's take place.

The period between each renegotiation is known as the lifetime. Generally, the shorter the lifetime, the more secure the IPsec tunnel (at the cost of more processor intensive IKE negotiations). With longer lifetimes, future VPN connections can be set up more quickly. By default, IKE phase I occurs once a day; IKE phase II occurs every hour but the time-out for each phase is configurable.

Configure the frequency of IKE and IPsec Security Associations in SmartConsole: VPN Community Properties > Advanced.

Perfect Forward Secrecy

The keys created by peers during IKE phase II and used for IPsec are based on a sequence of random binary digits exchanged between peers, and on the DH key computed during IKE phase I.

The DH key is computed once, then used a number of times during IKE phase II. Since the keys used during IKE phase II are based on the DH key computed during IKE phase I, there exists a mathematical relationship between them. For this reason, the use of a single DH key may weaken the strength of subsequent keys. If one key is compromised, subsequent keys can be compromised with less effort.

In cryptography, Perfect Forward Secrecy (PFS) refers to the condition in which the compromise of a current session key or long-term private key does not cause the compromise of earlier or subsequent keys. Security Gateways meet this requirement with a PFS mode. When PFS is enabled, a fresh DH key is generated during IKE phase II, and renewed for each key exchange.

However, because a new DH key is generated during each IKE phase I, no dependency exists between these keys and those produced in subsequent IKE Phase I negotiations. Enable PFS in IKE phase II only in situations where extreme security is required.

The supported DH groups for PFS are: 1, 2, 5, 14, 19, and 20. The default is group 2 (1042 bits).

Configure this in VPN Community Properties > Encryption > IKE Security Association (Phase 2) > Use Perfect Forward Secrecy.

Note - PFS mode is supported only between gateways, not between Security Gateways and remote access clients.

IP Compression

IP compression is a process that reduces the size of the data portion of the TCP/IP packet. Such a reduction can cause significant improvement in performance. IPsec supports the Flate/Deflate IP compression algorithm. Deflate is a smart algorithm that adapts the way it compresses data to the actual data itself. Whether to use IP compression is decided during IKE phase II. IP compression is not enabled by default.

IP compression is important for Remote Access client users with slow links.

Security Gateway encryption makes TCP/IP packets appear "mixed up". This kind of data cannot be compressed and bandwidth is lost as a result. If IP compression is enabled, packets are compressed before encryption. This has the effect of recovering the lost bandwidth.

Subnets and Security Associations

By default, a VPN tunnel is created for the complete subnets that host computers reside on, and not just for the host computers involved in the communication.

Unique SA Per Pair of Peers

If you disable the Support Key exchange for subnets option on each Security Gateway, you can create a unique Security Association for a pair of peers.

If the Security Gateway is configured to Support key exchange for subnets but the option is unsupported on the remote peer, when host A communicates with host C, a Security Association (SA 1) will be negotiated between host A's subnet and host C's IP address. The same SA is then used between any host on the 10.10.11.x subnet and Host C.

When host A communicates with host B, a separate Security Association (SA 2) is negotiated between host A's subnet and host B. As before, the same SA is then used between any host in 10.10.11.x subnet and Host B.

When Support Key exchange for subnets is not enabled on communicating Security Gateways, then a security association is negotiated between individual IP addresses; in effect, a unique SA per host.

IKE DoS Protection

Understanding DoS Attacks

Denial of Service (DoS) attacks are intended to reduce performance, block legitimate users from using a service, or even bring down a service. They are not direct security threats in the sense that no confidential data is exposed, and no user gains unauthorized privileges. However, they consume computer resources such as memory or CPU.

Generally, there are two kinds of DoS attack. One kind consists of sending malformed (garbage) packets in the hope of exploiting a bug and causing the service to fail. In the other kind of DoS attack, an attacker attempts to exploit a vulnerability of the service or protocol by sending well-formed packets. IKE DoS attack protection deals with the second kind of attack.

IKE DoS Attacks

The IKE protocol requires that the receiving Security Gateway allocates memory for the first IKE Phase 1 request packet that it receives. The Security Gateway replies, and receives another packet, which it then processes using the information gathered from the first packet.

An attacker can send many IKE first packets, while forging a different source IP address for each. The receiving Security Gateway is obliged to reply to each, and assign memory for each. This can consume all CPU resources, thereby preventing connections from legitimate users.

The attacker sending IKE packets can pretend to be a machine that is allowed to initiate IKE negotiations, such as a Check Point Security Gateway. This is known as an identified source. The attacker can also pretend to have an IP address that the receiving Security Gateway does not know about, such as a Remote Access client, or a Check Point Security Gateway with a dynamic IP address. This is known as an unidentified source.

Defense Against IKE DoS Attacks

When the number of simultaneous IKE negotiations handled exceeds the accepted threshold, it concludes that it is either under load or experiencing a Denial of Service attack. In such a case, the Security Gateway can filter out peers that are the probable source of a potential Denial of Service attack. The following sections describe different types of defenses against IKE DoS attacks.

IKE DoS protection is not supported for IPv6 addresses.

SmartConsole IKE DoS Attack Protection Settings

To protect against IKE DoS attacks, configure the SmartConsole IKE Denial of Service Protection settings, in the VPN >Advanced page of the Global Properties. IKE DoS protection is not supported for IPv6 addresses.

Support IKE DoS protection from identified source — The default setting for identified sources is Stateless. If the Security Gateway is under load, this setting requires the peer to respond to an IKE notification in a way that proves that the IP address of the peer is not spoofed. If the peer cannot prove this, the Security Gateway does not begin the IKE negotiation.
If the source is identified, protecting using Puzzles is over cautious, and may affect performance. A third possible setting is None, which means no DoS protection.
Support IKE DoS protection from unidentified source — The default setting for unidentified sources is Puzzles. If the Security Gateway is under load, this setting requires the peer to solve a mathematical puzzle. Solving this puzzle consumes peer CPU resources in a way that makes it difficult to initiate multiple IKE negotiations simultaneously.
For unidentified sources, Stateless protection may not be sufficient because an attacker may well control all the IP addresses from which the IKE requests appear to be sent. A third possible setting is None, which means no DoS protection.

Advanced IKE DoS Attack Protection Settings

Advanced IKE DoS attack protection can be configured on the Security Management server using the Check Point Database Tool (see sk13009). Configure the protection in the Global Properties shown. IKE DoS protection is not supported for IPv6.

ike_dos_threshold

Values: 0-100. Default: 70. Determines the percentage of maximum concurrent ongoing negotiations, above which the Security Gateway will request DoS protection. If the threshold is set to 0, the Security Gateway will always request DoS protection.

ike_dos_puzzle_level_identified_initiator

Values: 0-32. Default: 19. Determines the level of the puzzles sent to known peer Security Gateways. This attribute also determines the maximum puzzle level a Security Gateway is willing to solve.

ike_dos_puzzle_level_unidentified_initiator

Values: 0-32. Default: 19. Determines the level of the puzzles sent to unknown peers (such as Remote Access clients and DAIP Security Gateways). This attribute also determines the maximum puzzle level that DAIP Security Gateways and Remote Access clients are willing to solve.

ike_dos_max_puzzle_time_gw

Values: 0-30000. Default: 500. Determines the maximum time in milliseconds a Security Gateway is willing to spend solving a DoS protection puzzle.

ike_dos_max_puzzle_time_daip

Values: 0-30000. Default: 500. Determines the maximum time in milliseconds a DAIP Security Gateway is willing to spend solving a DoS protection puzzle.

ike_dos_max_puzzle_time_sr

Values: 0-30000. Default: 5000. Determines the maximum time in milliseconds a client is willing to spend solving a DoS protection puzzle.

ike_dos_supported_protection_sr

Values: None, Stateless, Puzzles. Default: Puzzles. When downloaded to a client, it controls the level of protection the client is willing to support.

Security Gateways use the ike_dos_protection_unidentified_initiator property (equivalent to the SmartConsole Global Property: Support IKE DoS Protection from unidentified Source) to decide what protection to require from remote clients, but / SecureClient clients use the ike_dos_protection. This same client property is called ike_dos_supported_protection_sr on the Security Gateway.

Protection After Successful Authentication

You can configure fields in GuiDBedit Tool (see sk13009) or dbedit (see skI3301) to protect against IKE DoS attacks from peers who may authenticate successfully and then attack a Security Gateway. These settings are configured in the Global Properties table and not per Security Gateway. By default these protections are off. Once you enter a value, they will be activated.

To limit the amount of IKE Security Associations (SA's) that a user can open, configure the following fields:

Type of VPN	Field	Recommended Value
Site to site	`number_of_ISAKMP_SAs_kept_per_peer`	5
Remote user	`number_of_ISAKMP_SAs_kept_per_user`	5

To limit the amount of tunnels that a user can open per IKE, configure the following fields:

Type of VPN	Field	Recommended Value
Site to site	`number_of_ipsec_SAs_per_IKE_SA`	30
Remote user	`number_of_ipsec_SAs_per_user_IKE_SA`	5

Client Properties

Some Security Gateway properties change name when they are downloaded to Remote Access VPN Clients. The modified name appears in the Userc.C file, as follows:

Property Names

Property Name on Gateway	User.C Property name on Client
ike_dos_protection_unidentified_initiator (Equivalent to the SmartConsole Global Property: Support IKE DoS Protection from unidentified Source)	ike_dos_protection or ike_support_dos_protection
ike_dos_supported_protection_sr	ike_dos_protection
ike_dos_puzzle_level_unidentified_initiator	ike_dos_acceptable_puzzle_level
ike_dos_max_puzzle_time_sr	ike_dos_max_puzzle_time

Configuring Advanced IKE Properties

IKE is configured in two places:

On the VPN community network object (for IKE properties).
On the Security Gateway network object (for subnet key exchange).

VPN Community Object - Encryption Settings

IPv6 automatically works with IKEv2 encryption only. The option that you select here, applies to IPv4 traffic.

To configure a VPN Community object:

In SmartConsole, click Open Object Explorer (Ctrl+E).
From the navigation tree, click VPN Communities.
Double-click the VPN Community object.
The Community object window opens and shows the Gateways page.
From the navigation tree, click Encryption.
Configure the settings.
Click OK and publish the changes.

Encryption Method

Encryption Method - For IKE phase I and II.
- IKEv2 only - Only support encryption using IKEv2. Security Gateways in this community cannot access peer gateways that support IKEv1 only.
- Prefer IKEv2, support IKEv1 - If a peer supports IKEv2, the Security Gateway will use IKEv2. If not, it will use IKEv1 encryption. This is recommended if you have a community of older and new Check Point Security Gateways.
- IKEv1 only - IKEv2 is not supported.

Encryption Suite

Use this encryption suite - Select the methods negotiated in IKE phase 2 and used in IPSec connections. Select and choose the option for best interoperability with other vendors in your environment.
- VPN-A or VPN B - See RFC 4308 for more information.
- Suite-B GCM-128 or 256 - See RFC 6379 for more information.
Custom encryption suite - If you require algorithms other than those specified in the other options, select the properties for IKE Phase 1, including which Diffie-Hellman group to use. Also, select properties for IKE Phase 2.
Note - Suite-B GCM-128 and 256 encryption suites are supported on R71.50 gateways and from R75.40 gateways.

If there is a Dynamic IP Gateway inside the community, R77.30 (or lower) community member gateways that respond to its IKE negotiation, use the configuration defined in Global Properties > Remote Access > VPN -Authentication and Encryption.

Use aggressive mode (Main mode is the default) - Select only if the peer only supports aggressive mode. This is only supported with IKEv1.
Use Perfect Forward Secrecy, and the Diffie-Hellman group - Select if you need extremely high security.
Support IP compression - Select to decrease bandwidth consumption and for interoperability with third party peers configured to use IP Compression.

VPN Community Object - Advanced Settings

Configure these options in the VPN Community object Advanced page:

IKE (Phase 1)

When to renegotiate the IKE Security Associations.

IKE (Phase 2)

When to renegotiate the IPsec security associations. This sets the expiration time of the IPsec encryption keys.

NAT

Disable NAT inside the VPN community - Select to not apply NAT for the traffic while it passes through IPsec tunnels in the community.

Reset

Reset all VPN properties to the default.

On the Gateway Network Object

On the IPsec VPN > VPN Advanced page, select one of the options in the VPN Tunnel Sharing section. There are several settings that control the number of VPN tunnels between peer gateways:
Note - Wire Mode is not supported for IPv6 connections.
- Use the community settings - Create the number of VPN tunnels as defined on the community Tunnel Management page.
- Custom settings:
  - One VPN tunnel per each pair of hosts - A VPN tunnel is created for every session initiated between every pair of hosts.
  - One VPN tunnel per subnet pair - After a VPN tunnel has been opened between two subnets, subsequent sessions between the same subnets will share the same VPN tunnel. This is the default setting and is compliant with the IPsec industry standard.
  - One VPN tunnel per Gateway pair - One VPN tunnel is created between peer gateways and shared by all hosts behind each peer gateway.
On the Capacity Optimization page, select limit Maximum concurrent IKE negotiations so you can maximize VPN throughput.
If you have many employees working remotely, you may want to raise the default values.