[Swan] question about pfsgroup

[Paul Wouters]

On Fri, 30 Mar 2018, Xinwei Hong wrote:

> Ping...

First let me say if you write an email on the 29th, and then try to
demand an answer 1 day later, you are actually _reducing_ the chance
of getting an answer. If you need next day support, you should look
at commercial support. Please do not do this again.

> Can anybody confirm the behavior? Or if I'm doing something wrong, I'd like to know.
> I see the similar behavior with racoon. But looks like Cisco is doing differently, according to this page. https://www.speaknetworks.com/what-is-ipsec-vpn-pfs-perfect-forward-secrecy/

> On Thu, Mar 29, 2018 at 5:05 PM, Xinwei Hong <xhong at skytap.com> wrote:
>       Hi
> If we have pfsgroup in phase2alg, ipsec will use it in ESP, e.g.
> phase2alg=aes128-sha1;modp1536
> 
> If we don't have it, e.g phase2alg=aes128-sha1, ipsec will use the DH group from phase 1 as pfsgroup.
> 
> How do I tell ipsec to not use any pfsgroup? I tried "pfs=no", however, if the remote peer has pfsgroup, it will still accept the request. sound like it follows what the spec says:
> 
> pfs
> 
> whether Perfect Forward Secrecy of keys is desired on the connection*(Aqs keying channel (with PFS, penetration of the key-exchange protocol does not compromise keys negotiated
> earlier); Since there is no reason to ever refuse PFS, Libreswan will allow a connection defined with pfs=no to use PFS anyway. Acceptable values are yes (the default) and no.
> 
> 
> Also, if both ends have totally different pfsgroup, libreswan can establish connection between two peers and both side seems have different settings. 
> 
> Why it still works when both end mismatches? Do we need to care about pfsgroup at all? This is the case between two libreswan. When connecting to other VPN stack, mismatch
> sometimes does not work.

Be aware there is a difference between ikev1 and ikev2. In ikev1 the IKE
SA is negotiated first, and then the ipsec is negotiated. In ikev2, the
IKE and (first) IPsec SA is negotiated at the same time. This means that
the first ipsec sa has the DH protection of the first (ike) pfs group.

Therefor, in IKEv2, it makes little sense to specify different PFS for
IKE and IPsec. So leave pfs=yes and only specify pfs in the ike= line,
and you get the same pfs for the first ike/ipsec and any further ipsec
sa's. If you have multiple ipsec sa's for one ike sa, you would never
know which connection is brought up first (under the first pfs group) and
which is brought up second (under the second pfs group). Therefor,
libreswan does not allow different pfs groups between ike/ipsec.

So the advise is to never specify the modp argument on the esp= line,
which means use the same one as used for ike.

There is one exception in the upcoming 3.24 release to work around a
Windows bug using the ms-dh-downgrade=yes option, which allows a
different (weaker) modp group because the Windows bug causes a rekey
to use the wrong group.

Paul