ESP proposals to offer for the CHILD_SA. A proposal is a set of algorithms. For non-AEAD ESP proposals, this includes an integrity algorithm, an encryption algorithm, an optional key exchange method and an optional Extended Sequence Number Mode indicator. For AEAD proposals, a combined mode algorithm is used instead of the separate encryption/integrity algorithms.
If a key exchange method is specified, CHILD_SA/Quick Mode rekeying and initial negotiation use a separate key exchange using the specified method. However, for IKEv2, the keys of the CHILD_SA created implicitly with the IKE_SA will always be derived from the IKE_SA's key material. So any key exchange method specified here will only apply when the CHILD_SA is later rekeyed or is created with a separate CREATE_CHILD_SA exchange. A proposal mismatch might, therefore, not immediately be noticed when the SA is established, but may later cause rekeying to fail.
With peers that support multiple IKEv2 key exchanges (RFC 9370), up to seven additional key exchanges may be negotiated. They can be configured by prefixing the algorithm keyword with keX_ (where X is a number between 1 and 7).
Extended Sequence Number support may be indicated with the esn and noesn values, both may be included to indicate support for both modes. If omitted, noesn is assumed.
For IKEv2, multiple algorithms of the same kind can be specified in a single proposal, from which one gets selected. For IKEv1, only one algorithm per kind is allowed per proposal, more algorithms get implicitly stripped. Use multiple proposals to offer different algorithm combinations with IKEv1.
Algorithm keywords get separated using dashes. The special value default forms a default proposal of supported algorithms considered safe, and is usually a good choice for interoperability. If no algorithms are specified for AH nor ESP, the default set of algorithms for ESP is included.
StrongSwan default: ["default"]
null or (list of string)null