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);
