AES-GCM should be an allowed encryption algorithm for IKEv2 in P1
Can see that GCM options for phase1 IPsec has been removed again at:
A few topics regarding this already exists but think its time to be sure that the correct options are available on the website for both IKEv1 and IKEv2
I have already commented something on github but I think a redesign is needed on the website, since IKEv2 doesnt have a concept of phase 1 and phase 2. The initial exchange in IKEv2 (known as Phase 1 in IKEv1) covers both the establishment of the IKE SA and establishment of the first child SA. Hence in IKEv2 there is no “phase 2” after the initial exchange (at least not until the first child SA needs to be rekeyed).
Communication using IKE always begins with IKE_SA_INIT and IKE_AUTH
exchanges (known in IKEv1 as Phase 1). These initial exchanges
normally consist of four messages, though in some scenarios that
number can grow. All communications using IKE consist of request/
response pairs. We'll describe the base exchange first, followed by
variations. The first pair of messages (IKE_SA_INIT) negotiate
cryptographic algorithms, exchange nonces, and do a Diffie-Hellman
Difference between IKEv1 and IKEv2
” Protection of IKE messages based on ESP, rather than a method
unique to IKE
IKEv2 uses the same protection for IKE messages as for ESP. So if one wants to use GCM for ESP, one will also have to use GCM for IKE messages.
Updated by Lars Pedersen over 5 years ago
strongswan also got a test configuration using GCM in both "IKE" and "ESP" parameter
Updated by Lars Pedersen about 5 years ago
Took the initiative and asked the strongswan mailing list if the AES-GCM was supported in IKEv2. The response is in the github commit link. So I think the webconfigurators IPsec section must be resigned for with a IKEv1 and IKEv2 layout since they are different.
Updated by Jim Pingle about 5 years ago
- Assignee set to Steve Beaver
- Target version set to 2.3.2
- Affected Version set to 2.3
Testing confirms that it does not work with IKEv1, as expected, but that it does work with IKEv2 following that strongSwan example.
Looks like we could accommodate it in the current GUI:
1. The AES-GCM options must only be shown for IKEv2, not IKEv1 (and rejected if somehow chosen for IKEv1, such as an upgrade from an older version that incorrectly allowed it)
2. A note or other nudge that it's best to use AES-XCBC for the "hash" (really PRF) when selecting AES-GCM for IKE in IKEv2.
For the immediate future, if someone needs GCM in p1 quickly, they could use this patch with the System Patches package (path strip = 2) to get the options back, but they'd show incorrectly for IKEv1, so it's not good to commit as-is: http://files.atx.pfsense.org/jimp/patches/gcmp1-2.3.x.patch
Updated by Michael Newton about 5 years ago
Can I suggest that in the meantime, there shouldn't be a default selection made for encryption algorithm? And further, perhaps a warning message displayed? It's poor form to remove a feature without any notice to the user; especially since it's not removed from the back end. So as long as you don't make any changes it keeps working!
I made a small change to our tunnel configuration a few days ago, not realizing that AES-GCM had been silently changed to AES when I saved the changes. The tunnel was stopped and started a couple of times afterwards, with no problems. But once the pfSense was rebooted and came back up, the tunnel was broken and people started yelling! Upgrade to 2.3 happened months ago.
Updated by Chris Buechler about 5 years ago
- Subject changed from Webconfiguration IPSec IKEv2 GCM option to AES-GCM should be an allowed encryption algorithm for IKEv2 in P1
- Status changed from New to Feedback
- Assignee changed from Steve Beaver to Chris Buechler
- Affected Version changed from 2.3 to 2.3.x