RFC 5996 does not
restrict the creation of multiple IKE SAs having the same remote IKE_ID (not
necessarily from the same peer). The remote IKE_ID specifies the remote peer
ID: IDi when the gateway is the responder, and IDr when the gateway is the
initiator. In such implementations, a new IKE_SA is created for every
IKE_SA_INIT/IKE_AUTH exchanges, unless INITIAL_CONTACT is indicated. If an
IKE_AUTH is received with INITIAL_CONTACT, the node is expected to delete all
IKE_SAs having the same authenticated identity.
The StarOS IPSec
stack does not currently support INITIAL_CONTACT.
When enabled via the
duplicate-session-detection command in a WSG service, only
one IKE_SA is allowed per remote IKE_ID. This feature is supported for WSG
service, both RAS (Remote Access Service) and S2S (Site-to-Site) tunnel types.
sequence of figures indicates how StarOS IPSec managers handle duplicate IKE_SA
scenarios when this feature is enabled.
Figure 1. No Duplicate Session Found
Figure 2. Duplicate Session Found in Same StarOS IPSec
Figure 3. Duplicate Session Found in Different StarOS IPSec
Figure 4. Duplicate Session Found When SecGW (WSG Service) is the
Figure 5. Internal Failures Encountered After Duplicate Session is
Duplicate Session Detection
Use the following
example to enable duplicate session detection: