[strongSwan] strongswan: clarification needed on rekeying failure

[gowrishankar]

Hi Martin,
Thought of checking with "keyingtries=1" when NO_PROPOSAL_CHOSEN is in
CREATE_CHILD_SA response.

 From charon.log:

[IKE] CHILD_SA tahi_ikev2_test{1} established with SPIs cdee854a_i 
e31e56a3_o and TS X:X:X:1::1/128 === Y:Y:Y:1::1/128
....
..
[KNL] received a XFRM_MSG_EXPIRE
[KNL] creating rekey job for ESP CHILD_SA with SPI cdee854a and reqid {1}
...
..
[IKE] received NO_PROPOSAL_CHOSEN notify, no CHILD_SA built
[IKE] failed to establish CHILD_SA, keeping IKE_SA
[IKE] CHILD_SA rekeying failed, trying again in 24 seconds
[JOB] next event in 3s 930ms, waiting
[KNL] deleting SAD entry with SPI cb23d44e
...
[KNL] sending XFRM_MSG_DELSA: => 40 bytes @ 0x7fabc6b4a830
...
[KNL] creating rekey job for ESP CHILD_SA with SPI e31e56a3 and reqid {1}
[MGR] checkout IKE_SA by ID
[MGR] IKE_SA tahi_ikev2_test[1] successfully checked out
[IKE] queueing CHILD_REKEY task
[IKE] activating new tasks
[IKE]   activating CHILD_REKEY task
...
..

I would like to know if "keyingtries" is applicable just after one 
CREATE_CHILD_SA
attempt or its count is including even first attempt to rekey. As I set 
its value to one
and I see in two places rekeying attempted, I am slightly confused here. 
Can you
clarify please.

Thanks,
Gowri Shankar

On Thursday 28 June 2012 01:27 PM, Martin Willi wrote:
> Hi,
>
>>    10[IKE] received NO_PROPOSAL_CHOSEN notify, no CHILD_SA built
>>    10[IKE] CHILD_SA rekeying failed, trying again in 24 seconds
>> Hence, is sending notify payload (no proposal chosen) not treated as
>> failure for rekey attempt?
> NO_PROPOSAL_CHOSEN usually indicates a permanent error, yes, but there
> are corner cases where a retry makes sense.
>
> RFC 5996 defines a TEMPORARY_FAILURE to indicate that rekeying is
> currently not possible (most likely because of an exchange collision),
> and the peer should try again. Before RFC 5996, there was no such
> specific notify, and NO_PROPOSAL_CHOSEN was used.
>
> We ourself still use a NO_PROPOSAL_CHOSEN notify in some of these
> situations. I think we should update to the new RFC 5996 notifies, but
> we haven't done this yet.
>
>> "If an SA has expired or is about to expire and rekeying attempts
>> using the mechanisms described here fail, an implementation MUST close
>> the IKE_SA and any associated CHILD_SAs and then MAY start new ones."
> Another reason for retrying is that the responder might have updated the
> configuration (for example, due to manual intervention). The hard SA
> lifetime still applies, and the SA gets deleted once expired. So I think
> we are fine with the above paragraph.
>
> Regards
> Martin
>
>