On Thu, Apr 11, 2019 at 04:32:28PM +0200, Tobias Heider wrote:
> Hi,
>
> this patch fixes a bug that appears after simultaneous
> rekeying of the ikesa. Currently the initiator does not set it's
> IKED_REQ_INFORMATIONAL flag when sending the delete request and thus rejects
> the response to the DELETE INFORMATIONAL request in ikev2_recv.
> The request is not removed from the initiators request queue and is
> retransmitted over and over.
>
> The bug can best be reproduced by configuring two iked peers with a short
> ikelifetime (e.g. 10) and looking for INFORMATIONAL receives on the
> responder side.
>
>
> Index: sbin/iked//ikev2.c
> ===================================================================
> RCS file: /mount/openbsd/cvs/src/sbin/iked/ikev2.c,v
> retrieving revision 1.168
> diff -u -p -u -r1.168 ikev2.c
> --- sbin/iked//ikev2.c 27 Feb 2019 06:33:56 -0000 1.168
> +++ sbin/iked//ikev2.c 11 Apr 2019 14:09:35 -0000
> @@ -3539,6 +3539,9 @@ ikev2_ikesa_delete(struct iked *env, str
> struct ikev2_delete *del;
>
> if (initiator) {
> + /* XXX: Can not have simultaneous INFORMATIONAL exchanges */
> + if (sa->sa_stateflags & IKED_REQ_INF)
> + goto done;
> /* Send PAYLOAD_DELETE */
> if ((buf = ibuf_static()) == NULL)
> goto done;
> @@ -3550,6 +3553,7 @@ ikev2_ikesa_delete(struct iked *env, str
> if (ikev2_send_ike_e(env, sa, buf, IKEV2_PAYLOAD_DELETE,
> IKEV2_EXCHANGE_INFORMATIONAL, 0) == -1)
> goto done;
> + sa->sa_stateflags |= IKED_REQ_INF;
> log_debug("%s: sent delete, closing SA", __func__);
> done:
> ibuf_release(buf);
>
This makes my iked connections much more stable.
- David
