IPsec and IKE

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) 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:

IKEv2 is supported inside VPN Communities working in Simplified mode.

IKEv2 is configured in the VPN Community A named collection of VPN domains, each protected by a VPN gateway. object > Encryption. The default setting is IKEv1 only.

IKEv2 is automatically always used for IPv6 traffic. The encryption method configuration applies to IPv4 traffic only.

To configure IKE settings for Remote Access VPN An encrypted tunnel between remote access clients (such as Endpoint Security VPN) and a Security Gateway. users in SmartConsole Check Point GUI application used to manage a Check Point environment - configure Security Policies, configure devices, monitor products and events, install updates, and so on., click Menu > Global properties > Remote Access > VPN - Authentication and Encryption.

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 SHA-512 AES-XCBC SHA -384	MD5 SHA1 (default) SHA-256 SHA-512 AES-XCBC SHA -384

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

The Diffie-Hellman key computation (also known as exponential key agreement) is based on the Diffie Hellman (DH) mathematical groups.

A Security Gateway Dedicated Check Point server that runs Check Point software to inspect traffic and enforce Security Policies for connected network resources. supports these DH groups during the two phases of IKE.

A Diffie-Hellman 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.

Between Security Gateways, there are two modes for IKE Phase I.

These modes only apply to IKEv1:

• IKEv1 Phase I - Main Mode

  This is the default.

  The Security Gateway performs the IKE negotiation with six packets.

  The Main Mode is preferred the Aggressive Mode 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 the Main Mode, the DH computation is performed after authentication.

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

• IKEv1 Phase I - Aggressive Mode

  The Security Gateway performs the IKE negotiation with three packets.

  Use the IKE Phase I Aggressive Mode when a Check Point Security Gateway needs to negotiate with third-party VPN solutions that do not support the IKE Phase I Main Mode.

When dealing with remote access, IKE has additional modes:

• Hybrid Mode - Provides an alternative to IKE phase I, where the Security Gateway is allowed to authenticate with certificates and the client via some other means, such as SecurID. For more information on Hybrid mode, see the R82 Remote Access VPN Administration Guide.

• Office Mode - This is an extension to the IKE protocol. The 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 this "config mode", the Remote Access VPN 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 R82 Remote Access VPN Administration Guide.

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 negotiations 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 > Objects menu > Object Explorer > VPN Communities > the VPN Community object properties > Advanced. After the changes, install the Access Control policy.

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. After the changes, install the Access Control policy.

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.

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.

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.

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.

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 PointSecurity 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 PointSecurity Gateway with a dynamic IP address. This is known as an unidentified source.

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.

Note - IKE DoS protection is not supported for IPv6 addresses.

To protect against IKE DoS attacks:

1. In SmartConsole, click Menu > Global properties > VPN > Advanced.

2. In the IKE Denial of Service protection section, configure these settings:

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

3. Click OK.

4. Install the Access Control Policy.

Note - IKE DoS protection is not supported for IPv6.

You can configure the advanced IKE DoS attack protection on the Management Server Check Point Single-Domain Security Management Server or a Multi-Domain Security Management Server. with Database Tool (GuiDBEdit Tool).

You can configure fields with Database Tool (GuiDBEdit Tool) 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 (SAs) that a user can open, configure the following fields:

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

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:

IPv6 automatically works with IKEv2 encryption only.

The option that you select here, applies to IPv4 traffic.

To configure a VPN Community object:

1. In SmartConsole, click Objects menu > Object Explorer (or press Ctrl+E).

2. From the left navigation tree, click VPN Communities.

3. Double-click the VPN Community object.

   The Community object window opens and shows the Gateways page.

4. From the navigation tree, click Encryption.

5. Configure the settings.

   Encryption Method - for IKE Phase I and IKE Phase II

   • IKEv2 only - Only support encryption with IKEv2. Security Gateways in this community cannot access peer Security 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.

   If there is a Security Gateway with Dynamically Assigned IP address inside the VPN Community, then R77.30 (or lower) Security Gateways that respond to its IKE negotiation, use the configuration defined in SmartConsole > Menu > Global properties > Remote Access > VPN -Authentication and Encryption.

   More

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

   • Quantum Safe Key Exchange - See Quantum Safe Key Exchange.

   • Support IP compression - Select to decrease bandwidth consumption and for interoperability with third party peers configured to use IP Compression.

   • Override Encryption for Externally Managed Gateways - See IPsec and IKE.

6. Click OK.

7. Install the Access Control Policy.

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.

Instructions

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

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