aboutsummaryrefslogtreecommitdiffstats
path: root/src/libstrongswan/plugins/sqlite/sqlite_database.c
diff options
context:
space:
mode:
authorMartin Willi <martin@revosec.ch>2014-04-10 11:25:32 +0200
committerMartin Willi <martin@revosec.ch>2014-04-17 09:59:06 +0200
commitf02cabbe358cc2f5636de0f7de7be114884302c3 (patch)
tree4c494c15a71b193e436953f1b81b00c759c2175f /src/libstrongswan/plugins/sqlite/sqlite_database.c
parent094963d1b16024c56adc624cc97729ce424e2814 (diff)
downloadstrongswan-f02cabbe358cc2f5636de0f7de7be114884302c3.tar.bz2
strongswan-f02cabbe358cc2f5636de0f7de7be114884302c3.tar.xz
ikev2: Reject CHILD_SA creation/rekeying while deleting an IKE_SA
If one peer starts reauthentication by deleting the IKE_SA, while the other starts CHILD_SA rekeying, we run in a race condition. To avoid it, temporarily reject the rekey attempt while we are in the IKE_SA deleting state. RFC 4306/5996 is not exactly clear about this collision, but it should be safe to reject CHILD_SA rekeying during this stage, as the reauth will re-trigger the CHILD_SA. For non-rekeying CHILD_SA creations, it's up to the peer to retry establishing the CHILD_SA on the reauthenticated IKE_SA.
Diffstat (limited to 'src/libstrongswan/plugins/sqlite/sqlite_database.c')
0 files changed, 0 insertions, 0 deletions