[strongSwan-dev] [PATCH 1/2] Enforce IKE_SA uniqueness policy as initiator too

Tobias Brunner tobias at strongswan.org
Wed Apr 27 12:14:48 CEST 2016

Hi Jan,

> In cases that both peers of tunnel try to initiate the connection
> simultaneously one of the peers ends up with having two IKE_SA in state
> IKE_ESTABLISHED. Therefore lets call check_uniqueness() before we switch
> state like it is already the case as a responder in build_r.

Wouldn't this result in both peers aborting the IKE_SA they each initiated?

Peer A                                Peer B
IKE_SA_INIT (A)     <-------------->  IKE_SA_INIT (B)
IKE_SA_INIT (B)     <-------------->  IKE_SA_INIT (A)
IKE_AUTH (A)        -----\    /-----  IKE_AUTH (B)
SA B ESTABLISHED    <-----\--/
IKE_AUTH (B)        ----\  \------->  SA A ESTABLISHED
                         \     /----  IKE_AUTH (A)
                          \---/---->  Finds duplicate A,
Finds duplicate B   <--------/        aborts B
aborts A

Mutual duplicate checking would require something similar to what's done
to resolve rekey collisions (e.g. comparing nonces).  But since that's
not standardized this would require some kind of private extension (it
only works if both peers behave the same otherwise you could still end
up without any SAs).  And with current versions duplicate SAs aren't
really an issue anymore.


More information about the Dev mailing list