  <varlistentry>
  <term><emphasis remap='B'>ike</emphasis></term>
  <listitem>
<para>IKE encryption/authentication algorithm to be used
for the connection (phase 1 aka ISAKMP SA or IKE SA). If this option is not
set, the builtin defaults will be used. This is the preferred method, and allows
for gradual automatic updates using the same configuration. Some distributions,
such as Fedora and RHEL/CentOS, use a System Wide Crypto Policy that sets the
default ike= (and esp=) lines. Specifying your own ike= line means overriding
all these system or software recommended defaults, but can be necessary at
times. Note that libreswan does not support using a PRF algorithm that is
different from the INTEGRITY (hash) algorithm by design.</para>
<para> 
The format is <emphasis remap='I'>"cipher-hash;modpgroup, cipher-hash;modpgroup, ..."</emphasis>
Any omitited option will be filled in with <emphasis remap='B'>all</emphasis>
allowed default values. Multiple proposals are separated by a comma. If an
<emphasis remap='B'>ike=</emphasis> line is specified, no other received proposals
will be accepted than those specified on the IKE line.
Some examples are
<emphasis remap='B'>ike=3des-sha1,aes-sha1</emphasis>,
<emphasis remap='B'>ike=aes</emphasis>,
<emphasis remap='B'>ike=aes_ctr</emphasis>,
<emphasis remap='B'>ike=aes_gcm256-sha2</emphasis>,
<emphasis remap='B'>ike=aes128-md5;modp2048</emphasis>,
<emphasis remap='B'>ike=aes256-sha2;dh19</emphasis>,
<emphasis remap='B'>ike=aes128-sha1;dh22</emphasis>,
<emphasis remap='B'>ike=3des-md5;modp1024,aes-sha1;modp1536</emphasis>.
</para><para>
IKEv2 allows combining elements into a single proposal. These can be specified by using the +
symbol. An example is:
<emphasis remap='B'>ike=aes_gcm+chacha20_poly1305;dh14+dh19,aes+3des-sha2+sha1;dh14</emphasis>.
Note that AEAD algorithms (aes_gcm, aes_ccm, chacha20_poly1305) and non-AEAD algorithms (aes, 3des)
cannot be combined into a single proposal. To support aes and aes_gcm, two proposals separated by
a comma must be used.</para>

<para>
The default IKE proposal depends on the version of libreswan used. It
follow the recommendations of RFC4306, RFC7321 and as of this writing
their successor draft documents RFC4306bis and RFC7321bis.  As for
libreswan 3.32, SHA1 and MODP1536(dh5) are still allowed per default
for backwards compatibility, but 3DES and MODP1024(dh2) are not allowed
per default. As of libreswan 4.x, modp1024(dh2) support is no longer
compiled in at all. For IKEv2, the defaults include AES, AES-GCM, DH14
and stronger, and SHA2.  The default key size is 256 bits. The default
AES_GCM ICV is 16 bytes.
</para>

<para>
Note that AES-GCM is an AEAD algorithm, meaning that it performs
encryption+authentication in one step. This means that AES-GCM must not
specify an authentication algorithm. However, for IKE it does require
a PRF function, so the second argument to an AEAD algorithm denotes the
PRF. So ike=aes_gcm-sha2 means propose AES_GCM with SHA2 as the prf. Note
that for phase2alg, there is no prf, so AES-GCM is specified for ESP as
esp=aes_gcm-null. The AES-GCM and AES-CCM algorithms support 8,12 and 16
byte ICV's.  These can be specified using a postfix, for example aes_gcm_a
(for 8), aes_gcm_b (for 12) and aes_gcm_c (for 16).  The default (aes_gcm
without postfix) refers to the 16 byte ICV version. It is strongly
recommended to NOT use the 8 or 12 byte versions of GCM or CCM. These
versions are NOT included in the default and will be removed in a future
version, following the recommendation of RFC 8247 or it successor.
</para>

<para>
Weak algorithms are regularly removed from libreswan. Currently, 1DES
and modp768(DH1) have been removed and modp1024(DH2) has been disabled
at compile time. Additionally, MD5 and SHA1 will be removed within the
next few years. Null encryption is available, and should only be used
for testing or benchmarking purposes. Please do not request for insecure
algorithms to be re-added to libreswan. IKEv1 has been disabled per default,
and will soon no longer be compiled in by default.
</para>

<para>
For all Diffie-Hellman groups, the "dh" keyword
can be used instead of the "modp" keyword. For example
<emphasis>ike=3des-sha1;dh19</emphasis>. Diffie-Hellman groups 19,20 and
21 from RFC-5903 are supported. Curve25519 from RFC-8031 is supported as
"dh31". Curve448 and GOST DH groups are not yet supported in libreswan
because these are not supported yet in the NSS crypto library.
</para>

<para>
Diffie-Hellman groups 22, 23 and 24 from RFC-5114 are implemented but not
compiled in by default.  These DH groups are extremely controversial and
MUST NOT be used unless forced (administratively) by the other party. This
is further documented in RFC 8247, but the summary is that it cannot
be proven that these DH groups do not contain a cryptographic trapdoor
(a backdoor by the USG who provided these primes without revealing the
seeds and generation process used).
</para>
<para>The modp syntax will be removed in favour of the dh syntax in the future</para>
  </listitem>
  </varlistentry>

