From: Martin Willi <martin@revosec.ch>
Date: Fri, 1 Nov 2013 10:28:53 +0000 (+0100)
Subject: ike: Don't immediately DPD after deferred DELETEs following IKE_SA rekeying
X-Git-Tag: 5.1.2dr1~45
X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=b76e96e2ef4d56c863b36c8d3c39e3c2efcf4a7c;p=thirdparty%2Fstrongswan.git

ike: Don't immediately DPD after deferred DELETEs following IKE_SA rekeying

Some peers seem to defer DELETEs a few seconds after rekeying the IKE_SA, which
is perfectly valid. For short(er) DPD delays, this leads to the situation where
we send a DPD request during set_state(), but the IKE_SA has no hosts set yet.
Avoid that DPD by resetting the INBOUND timestamp during set_state().
---

diff --git a/src/libcharon/sa/ike_sa.c b/src/libcharon/sa/ike_sa.c
index 0282087827..d482f8b49c 100644
--- a/src/libcharon/sa/ike_sa.c
+++ b/src/libcharon/sa/ike_sa.c
@@ -687,6 +687,14 @@ METHOD(ike_sa_t, set_state, void,
 					DBG1(DBG_IKE, "maximum IKE_SA lifetime %ds", t);
 				}
 				trigger_dpd = this->peer_cfg->get_dpd(this->peer_cfg);
+				if (trigger_dpd)
+				{
+					/* Some peers delay the DELETE after rekeying an IKE_SA.
+					 * If this delay is longer than our DPD delay, we would
+					 * send a DPD request here. The IKE_SA is not ready to do
+					 * so yet, so prevent that. */
+					this->stats[STAT_INBOUND] = this->stats[STAT_ESTABLISHED];
+				}
 			}
 			break;
 		}