Project

General

Profile

Issue #2825

I would like to know difference between uniqueids=no and yes

Added by Xiaoqiang Fu almost 2 years ago. Updated almost 2 years ago.

Status:
Closed
Priority:
Normal
Category:
configuration
Affected version:
5.6.1
Resolution:
No change required

Description

Hi expert,

In wiki ConfigSetupSection page, there is a paragraph to explain uniqueids. I'm a little confused with "yes" and "no", "yes" is for "The daemon also accepts the value replace", "no" is for "the daemon will replace old IKE_SAs". It seems they act samely. Could you comment what is different of them?

uniqueids = yes | no | never | replace | keep

whether a particular participant ID should be kept unique, with any new IKE_SA using an ID
deemed to replace all old ones using that ID. Participant IDs normally are unique, so a new
IKE_SA using the same ID is almost invariably intended to replace an old one.
The difference between no and never is that the daemon will replace old IKE_SAs when receiving an
INITIAL_CONTACT notify if the option is no but will ignore these notifies if never is configured.
The daemon also accepts the value replace which is identical to yes and the value keep to reject
new IKE_SA setups and keep the duplicate established earlier.

Regards,
Yang Li

ipsec.conf (1.04 KB) ipsec.conf Xiaoqiang Fu, 15.11.2018 04:35

History

#1 Updated by Xiaoqiang Fu almost 2 years ago

And how to trigger initiator to send INITIAL_CONTACT?

ipsec.conf is similar in local and remote as enclosed ipsec.conf.

#2 Updated by Tobias Brunner almost 2 years ago

  • Category set to configuration
  • Status changed from New to Feedback

"yes" is for "The daemon also accepts the value replace"

"yes" is simply the same as "replace" (i.e. a new IKE_SA with the same identities will replace any existing ones).

"no" is for "the daemon will replace old IKE_SAs".

Only if the client sends an INITIAL_CONTACT notify is the behavior the same as "yes", if the client doesn't send one, SAs with the same identities are kept as is the new one. Use "never" to ignore INITIAL_CONTACT notifies sent by the client and keep all SAs with the same identities.

And how to trigger initiator to send INITIAL_CONTACT?

It's sent if there are no established IKE_SAs with the same identities (so the identities have to be known, it will not be sent if the remote identity contains wildcards or is e.g. %any). It can be disabled completely by setting uniqueids to "never" (prior to 5.6.1 "no" also had that effect).

#3 Updated by Xiaoqiang Fu almost 2 years ago

"yes" is simply the same as "replace" (i.e. a new IKE_SA with the same identities will replace any existing ones).

Whether it has nothing with INITIAL_CONTACT?

if the client doesn't send one, SAs with the same identities are kept as is the new one.

Without INITIAL_CONTACT, old and new SAa are kept?

#4 Updated by Xiaoqiang Fu almost 2 years ago

It's sent if there are no established IKE_SAs with the same identities (so the identities have to be known, it will not be sent if the remote identity contains wildcards or is e.g. %any).

Could you introduce scenario why same identities is a must condition? Why not always send INITIAL_CONTACT when try to create IKE_SA if no established IKE_SA?

#5 Updated by Tobias Brunner almost 2 years ago

"yes" is simply the same as "replace" (i.e. a new IKE_SA with the same identities will replace any existing ones).

Whether it has nothing with INITIAL_CONTACT?

An INITIAL_CONTACT notify always forces the replacement of other IKE_SAs with the same identities (there is e.g. no detection for a potential reauthentication, which is the case if no INITIAL_CONTACT notify was received and the identities are the same).

if the client doesn't sent one, SAs with the same identities are kept as is the new one.

Without INITIAL_CONTACT, old and new SAa are kept?

Yes, unless the server suspects it is a reauthentication (if the client IP and port are also the same).

Could you introduce scenario why same identities is a must condition? Why not always send INITIAL_CONTACT when try to create IKE_SA if no established IKE_SA?

Because it's obviously not an "initial contact" if an IKE_SA with the same identities is already established (the IP address family is actually also incorporated in that check, so it's possible to have two IKE_SAs with the same identities as long as one is over IPv4 and the other over IPv6).

#6 Updated by Xiaoqiang Fu almost 2 years ago

Hi Tobias,
Please close this topic, which has been clarified.

Regards,
Yang Li

#7 Updated by Tobias Brunner almost 2 years ago

  • Status changed from Feedback to Closed
  • Assignee set to Tobias Brunner
  • Resolution set to No change required

Also available in: Atom PDF