[Swan] question about pfsgroup

Andrew Cagney andrew.cagney at gmail.com
Mon Apr 23 17:39:16 UTC 2018


I'm not sure that the recent changes, mostly about IKEv2, will help here:

On 21 April 2018 at 20:56, Xinwei Hong <xhong at skytap.com> wrote:
> Sure. Thank you! I will try it out.
>
> Xinwei
>
>
>> On Apr 21, 2018, at 1:56 PM, Paul Wouters <paul at nohats.ca> wrote:
>>
>>> On Mon, 2 Apr 2018, Xinwei Hong wrote:
>>>
>>> I'm still using libreswan 3.20. Both ends are using default ikev2=permit. So, ikev1 is used in my test cases. What I observed is that VPN still works even when pfsgroup does not match.
>>> (either no pfsgroup, or different group value).
>>> I feel sometime it's hard to determine from log what pfsgroup it's actually using. If I see this:
>>> Apr  2 20:17:53 vvr-10-69-244-19 pluto[10391]: vpn-5653427: "conn_vpn-5653427-tunnel-VPNRemoteRoutedSubnet-tunnel-10.30.0.0/16" #377: initiating Quick Mode
>>> PSK+ENCRYPT+TUNNEL+PFS+UP+IKEV1_ALLOW+IKEV2_ALLOW+SAREF_TRACK+IKE_FRAG_ALLOW+ESN_NO to replace #376 {using isakmp#4 msgid:9a47d103 proposal=3DES(3)_000-SHA1(2) pfsgroup=MODP1024}
>>> does it mean that modp1024 is used?

In IKEv2, which I do know, things are straight forward.  If an end
requires DH then DH must be negotiated; and the log file will reflect
this.  But this is IKEv1 which I avoid ...

The above log line is just indicating what this end is going to send
across the wire as a proposal.  It doesn't indicate the outcome.
Instead, later, a line like:

    "westnet-eastnet" #2: STATE_QUICK_I2: sent QI2, IPsec SA
established tunnel mode {ESP=>0xaa33b26e <0xa8c9432e
xfrm=AES_CBC_128-HMAC_SHA1_96 NATOA=none NATD=none DPD=passive}

will appear showing what was established.

To your point, this contains nothing to explicitly confirm that PFS
was used (DH keys exchanged)  (by looking at debug logs I can tell, in
the above case, it was but you shouldn't need to do that).

However, skimming through the IKEv1 RFC it seems a PFS proposal is
should result in PFS vis
https://tools.ietf.org/html/rfc2409#section-5.5 (Phase 2 - Quick
Mode):

   All offers made during a Quick Mode are logically related and must be
   consistant. For example, if a KE payload is sent, the attribute
   describing the Diffie-Hellman group (see section 6.1 and [Pip97])
   MUST be included in every transform of every proposal of every SA
   being negotiated.

and https://tools.ietf.org/html/rfc2409#section-5 (Exchanges):

   During security association negotiation, initiators present offers
   for potential security associations to responders. Responders MUST
   NOT modify attributes of any offer, attribute encoding excepted (see
   Appendix A).  If the initiator of an exchange notices that attribute
   values have changed or attributes have been added or deleted from an
   offer made, that response MUST be rejected.

However, an addition to the log making this clear would be nice?

>>> When I specify "pfs=no", at first it will have:
>>> Apr  2 20:23:27 vvr-10-69-244-19 pluto[18354]: vpn-5653427: "conn_vpn-5653427-tunnel-VPNRemoteRoutedSubnet-tunnel-10.30.0.0/16" #2: initiating Quick Mode
>>> PSK+ENCRYPT+TUNNEL+UP+IKEV1_ALLOW+IKEV2_ALLOW+SAREF_TRACK+IKE_FRAG_ALLOW+ESN_NO {using isakmp#1 msgid:de62bfd4 proposal=3DES(3)_000-SHA1(2) pfsgroup=no-pfs}
>>> when it rekeys later(set to expire after 1 minute), it shows
>>> Apr  2 20:24:13 vvr-10-69-244-19 pluto[18354]: vpn-5653427: "conn_vpn-5653427-tunnel-VPNRemoteRoutedSubnet-tunnel-10.30.0.0/16" #5: initiating Quick Mode

Something flipped the PFS bit, causing the re-key to request a DH exchange!

Anyone?

>>> PSK+ENCRYPT+TUNNEL+PFS+UP+IKEV1_ALLOW+IKEV2_ALLOW+SAREF_TRACK+IKE_FRAG_ALLOW+ESN_NO to replace #3 {using isakmp#4 msgid:38e9b07b proposal=3DES(3)_000-SHA1(2) pfsgroup=MODP1024}
>>> what should I trust to find out the pfsgroup in use?
>>> At the same time, the other is actually racoon and have "pfs_group modp1536;". Seems mismatches do not affect either part.

My hunch is that pfs_group applies to connections racoon initiates.
As a responder, it is happy to go with what ever was proposed.



>> This code is currently in flux, so I would really recommend you re-test
>> this against a 3.24rcX release candidate from download.libreswan.org.
>>
>> We are still touching the related code over the next few days, os maybe
>> wait a few days before redoing your tests?
>>
>> Note we are somewhat forgiving if no pfs was negotiated and it still is
>> done, because doing it is always better then not doing it.
>>
>> Paul
> _______________________________________________
> Swan mailing list
> Swan at lists.libreswan.org
> https://lists.libreswan.org/mailman/listinfo/swan


More information about the Swan mailing list