ike: Don't immediately DPD after deferred DELETEs following IKE_SA rekeying
authorMartin Willi <martin@revosec.ch>
Fri, 1 Nov 2013 10:28:53 +0000 (11:28 +0100)
committerMartin Willi <martin@revosec.ch>
Fri, 1 Nov 2013 10:33:29 +0000 (11:33 +0100)
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().

src/libcharon/sa/ike_sa.c

index 0282087..d482f8b 100644 (file)
@@ -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;
                }