[Swan-dev] IKEv2 responder rekey code is fooed

[Andrew Cagney]

On Sun, 19 Apr 2020 at 10:20, Andrew Cagney <andrew.cagney at gmail.com> wrote:

>
>
> On Sun, 19 Apr 2020 at 06:57, Antony Antony <antony at phenome.org> wrote:
>
>> Dear fellow developers.
>>
>> I just noticed the IKEv2 IPsec rekey responder code has regressed beyond
>> recognition! too many changes after the main regression:) While trying to
>> figure out I notice logging and debugging lines changed too (possibly
>> old)
>> some with STATE_ and other without the prefix STATE_.  This make it hard
>> to
>> follow the regression.
>>
>> I suggest we take pause and retrace the steps. Also changing IKEv2 STATE_
>> is
>> , as I recollect, discontented issue. And I feel change has been sneaked
>> in.
>> Also use of some with STATE_ and others without "STATE_" is annoying.
>>
>
>
>> Main issue: rekey regression seems to started with 8abf1c415a.
>> currently the pattern is
>>
>> https://testing.libreswan.org/v3.30-456-g8abf1c415a-master/ikev2-child-rekey/OUTPUT/east.pluto.log.gz
>>
>> child state #3: V2_CREATE_R0(established IKE SA) =>
>> V2_IPSEC_R(established CHILD SA)
>>
>> that state transition for #3 seems wrong, it is not re-key transition. I
>> can't be sure because we have many log changes etc. But one thing is sure
>> #master is taking same weird code path for IKEv2 rekey responder.
>>
>
> So this:
>
> Apr  9 11:04:43.134196: | state #1 forced to match CREATE_CHILD_SA from STATE_V2_CREATE_R0->STATE_V2_IPSEC_R by ignoring from state
> Apr  9 11:04:43.134276: | selected state microcode Respond to CREATE_CHILD_SA IPsec SA Request
> Apr  9 11:04:43.134428: | #1 updating local interface from 192.1.2.23:500 to 192.1.2.23:500 using md->iface (in update_ike_endpoints() at state.c:2675)
>
> should have matched the child rekey transition?
>

I'm testing a fix (two transitions got reversed).

Is there a test that shows fails after 8abf1c415a?


>
>
>
>>
>> Before this regression: state transition appears to do the right thing.
>>
>>
>> https://testing.libreswan.org/v3.30-455-g221d720f48-master/ikev2-child-rekey/OUTPUT/east.pluto.log.gz
>> rekey seems to follow what is expected.
>>
>> child state #3: V2_CREATE_R0(established IKE SA) =>
>> V2_REKEY_CHILD_R0(established IKE SA)
>>
>> child state #3: V2_REKEY_CHILD_R0(established IKE SA) =>
>> V2_IPSEC_R(established CHILD SA)
>>
>> 2. log/debug started using short names and mixing them with long state
>> names.  This should not happen! Please keep the state names long and
>> consistent.
>>
>> switching IKEv2 MD.ST from CHILD #3 V2_CREATE_R0 to CHILD #3
>> V2_CREATE_R0
>>
>> In some other parts of the log it is full name.
>>
>> please keep the full name.
>>
>> "east" #4 complete v2 state STATE_V2_REKEY_CHILD_R0 transition with
>> STF_SUSPEND suspended from complete_v2_state_transition:3399
>>
>> NOTE: because of changes to state names since 8abf1c415a  in master you
>> will
>> see.
>>
>>
>> https://testing.libreswan.org/v3.30-507-ge06a82880f-master/ikev2-child-rekey/OUTPUT/east.pluto.log.gz
>> Apr 18 23:52:26.316312: | child state #3: V2_NEW_CHILD_R0(established IKE
>> SA) => V2_IPSEC_R(established CHILD SA)
>>
>> It should be something like STATE_V2_REKEY_CHILD_R0 =>
>> STATE_V2_IPSEC_R(established)
>>
>> -antony
>>
>> PS: at first glance initiator code seems ok. Again hard to say becuase of
>> log changes.
>> _______________________________________________
>> Swan-dev mailing list
>> Swan-dev at lists.libreswan.org
>> https://lists.libreswan.org/mailman/listinfo/swan-dev
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.libreswan.org/pipermail/swan-dev/attachments/20200419/0ebdb001/attachment.html>