Google Distributed Cloud (GDC) air-gapped VPN supports the following ciphers and configuration parameters for peer VPN gateways.
Proposal order
GDC VPN can act as an initiator or a responder to IKE requests depending on the origin of traffic when a new security association (SA) is needed.
When GDC VPN initiates a VPN connection, GDC VPN proposes the algorithms in the order shown in the supported cipher tables for each cipher role. The peer VPN gateway receiving the proposal selects an algorithm.
If the peer VPN gateway initiates the connection, then GDC VPN selects a cipher from the proposal by using the same order shown in the table for each cipher role.
Depending on which side is the initiator or the responder, the selected cipher can be different. For example, the selected cipher might even change over time as new security associations (SAs) are created during key rotation.
To prevent frequent changes in cipher selection, configure your peer VPN gateway to propose and accept only one cipher for each cipher role. This cipher must be supported by both GDC air-gapped VPN and your peer VPN gateway. Don't provide a list of ciphers for each cipher role. This best practice ensures that both sides of your GDC air-gapped VPN tunnel always select the same IKE cipher during IKE negotiation.
IKE fragmentation
GDC VPN supports IKE fragmentation as described by the IKEv2 fragmentation protocol: https://www.rfc-editor.org/rfc/rfc7383.
For best results, Google recommends that you enable IKE fragmentation, if it is not already enabled, on your peer VPN gateway.
If you don't have IKE fragmentation enabled, IKE packets from GDC to the peer VPN gateway that are larger than the gateway MTU are dropped.
Some IKE messages can't be fragmented, including the following messages:
IKE_SA_INITIKE_SESSION_RESUME
For more information, see the Limitations section in https://www.rfc-editor.org/rfc/rfc7383.
Supported cipher tables
These supported cipher tables provide the rules for substituting characters or groups of characters during the encryption and decryption processes.
Phase 1
| Cipher role | Cipher | Notes |
|---|---|---|
| Encryption & Integrity |
|
In this list, the first number is the size of the ICV parameter in bytes (octets), and the second is the key length in bits. Some documentation might express the ICV parameter (the first number) in bits instead (8 becomes 64, 12 becomes 96, and 16 becomes 128). |
| Pseudo-Random Function (PRF) |
|
Many devices don't require an explicit PRF setting. |
| Diffie-Hellman (DH) |
|
|
| Phase 1 lifetime | 36,000 seconds (10 hours) |
Phase 2
| Cipher role | Cipher | Notes |
|---|---|---|
| Encryption & Integrity |
|
In this list, the first number is the size of the ICV parameter in bytes (octets), and the second is the key length in bits. Some documentation might express the ICV parameter (the first number) in bits instead (8 becomes 64, 12 becomes 96, and 16 becomes 128). |
| Pseudo-Random Function (PRF) |
|
Many devices don't require an explicit PRF setting. |
| Diffie-Hellman (DH) |
|
|
| Phase 2 lifetime | 10,800 seconds (3 hours) |