[Swan-dev] changes to how ;DH is handled in esp/ah= proposals

Andrew Cagney andrew.cagney at gmail.com
Mon Apr 23 14:47:02 UTC 2018


The way ; is dealt with by the proposal parser has changed.  It should
eliminate some ambiguity, and ensure things are more consistent
between IKEv1 and IKEv2 ESP/AH and IKE.  After some to and fro, the
rules have been reduced to:

1. when pfs=no, specifying DH in an ESP/AH proposal is an error
previously: ;DH (and -DH) were being silently ignored

2. when pfs=yes, either all or none of the ESP/AH proposal explicitly specify DH
previously: ;DH, when put at the end of a list of ESP/AH proposals,
was interpreted as applying to all the proposals

Fine print:

2.1 IKEv1 only supports one type of DH algorithm, so if specified it
needs to be identical across the proposals; I suspect the restriction
comes from quick mode, but it might be due to how pluto implements
quick mode
2.2 IKEv2 only supports one type of DH algorithm and 'none', this is
because IKEv2 doesn't implement INVALID_KE during a CREATE_CHILD_SA
exchange

For instance, this is no longer valid:

    aes,aes_gcm;dh21

- when PFS=no, dh21 is invalid and should be removed, vis:

    aes,aes_gcm

- when PFS=yes, dh21 should either be removed or also added to aes. vis:

    aes,aes_gcm
    aes;dh21,aes_gcm;dh21

- and 2.1 allows:

    (IKEv2) aes_gcm;dh21,aes;none

Regardless, my recommendation is to just remove ;DH.

Andrew


More information about the Swan-dev mailing list