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.
Getting Here - SmartConsole > Security Policies > Access Control > Policy > Access Tools > VPN Communities > Star/Mesh Community > Encryption |
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.
IKE Security Association (Phase 1)
IKE Security Association (Phase 2)
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.
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.