[strongSwan] strongswan: clarification needed on rekeying failure

[gowrishankar]

Hi Martin,

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.
>

Yes, it is better explained in RFC 5996. So, any suggestion that if I 
should raise
a bug to improve this error handling in strongswan ?

>> "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.
>
Agree.

Thanks for the very useful reference you shared,
Gowri Shankar
> Regards
> Martin
>
>