VPN Communities - Encryption

What can I do here?

Use this window to set the Encryption Methods and Suites used by Community Members when exchanging keys or handling IPSec connections.

Selecting Encryption Methods

The methods selected depend on the organization's security policy, government regulations or other considerations such as encryption and integrity strength, or performance issues. Methods selected here apply to the whole community.

If different levels of encryption or different integrity methods are required between Security Gateways, consider defining additional communities, each with the relevant Security Gateways and methods.

Encryption Options

• Encryption Method - For IKE phase I and II.
  • IKEv1 for IPv4 and IKEv2 for IPv6 only.
  • 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.
• Encryption Suite - The methods negotiated in IKE phase 2 and used in IPSec connections. Select the option for best interoperability with other vendors in your environment.
  • Suite-B GCM-256 - (AES-GCM-256, SHA-384, EC Diffie-Hellman Group 20). See RFC 6379.
  • VPN B - (AES, AES-XCBC, Diffie-Hellman Group 14)). See RFC 4308.
  • VPN-A - (3DES, SHA-1, Diffie-Hellman Group 2). See RFC 4308.
  • Suite-B GCM-128 - (AES-GCM-128, SHA-256, EC Diffie-Hellman Group 19). See RFC 6379
• Custom Encryption Suite - If you require algorithms other than those specified above. Select these properties for IKE Phase 1 and 2.

  IKE Security Association (Phase 1)

  • Encryption Algorithm
  • Data Integrity
  • Diffie-Hellman Group
  • Use Aggressive mode - In aggressive mode, the Diffie-Hellman computation is performed parallel to authentication. A peer that is not yet authenticated can force processor intensive Diffie-Hellman computations on the other peer. Aggressive mode performs the IKE negotiation with three packets instead of six.

  IKE Security Association (Phase 2)

  • Encryption Algorithm
  • Data Integrity
  • Use 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 DH group used during PFS mode is configurable between groups 1, 2, 5 and 14, with group 2 (1042 bits) being the default.

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

  • Support 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/DeflateIP 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 SecuRemote / SecureClient users with slow links. For Example, dialup modems do compression as a way of speeding up the link. 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.