Subject: RE: UNIQUENESS clause of ipSecIkeRuleTable

From: MORAND Pierrick FTRD/DMI/CAE <[email-masked]>
Date: Mon, 1 Oct 2001 15:52:57 +0200

Hi !

ipSecRuleTable has effectively the same issue. I agree with you that
ipSecRuleIpSecSelectorGroupId needs to be added to the UNIQUENESS, and this
should be enought.

Concerning the question : "can there be more than one IKE associations
between two end points?", I must admit that I have no clear opinion on that
point, sorry ! I assume that implementations that would support this feature
would be able to tightly map Ipsec and Ike associations, but I don't know if
IKE allows that and if so, if some implementation support it. May be other
IpSec/IKE experts have already thought about it ???

Thanks for your reply.
Pierrick.

-----Message d'origine-----
De : Li Man.M (NRC/Boston) [mailto:[email-masked]]
Envoyé : mardi 25 septembre 2001 23:39
À : 'ext MORAND Pierrick FTRD/DMI/CAE'; IPSEC-POLICY (E-mail)
Objet : RE: UNIQUENESS clause of ipSecIkeRuleTable

Hi Pierrick,

Thanks for pointing this out. Would the addition of
ipSecIkeRuleIkeEndpointGroupId into the UNIQUENESS be good enough? It
boils down to the question of "can there be more than one IKE
associations between two end points?" If the answer is yes, then
ipSecIkeRuleIkeAssiciationId needs to be added too.

I start to think that the ipSecRuleTable has the same issue. The
ipSecruleIpSecSelectorGroupId needs to be added to the UNIQUENESS. What
do you think?

Thanks for your comments
Man 

-----Original Message-----
From: ext MORAND Pierrick FTRD/DMI/CAE
[mailto:[email-masked]]
Sent: September 20, 2001 04:20 AM
To: IPSEC-POLICY (E-mail)
Subject: UNIQUENESS clause of ipSecIkeRuleTable

Hi !

In the ipSecIkeRuleTable the UNIQUENESS clause is currently the
following :
UNIQUENESS {
       ipSecIkeRuleIfName,
       ipSecIkeRuleRoles
       }
Doing so, this prevents the PDP to install, for an interface having a
given
Role/IfName tuple value, different Ike policies for different peers. 

Shouldn't this clause be set to :
UNIQUENESS {
       ipSecIkeRuleIfName,
       ipSecIkeRuleRoles
       ipSecIkeRuleIkeAssiciationId ReferenceId,
//for the editor : to be renamed in ipSecIkeRuleIkeAssociationId
       ipSecIkeRuleIkeEndpointGroupId TagReferenceId
       }
I have excluded the ipSecIkeRuleIpSecRuleTimePeriodGroupId in order to
avoid
that an IkeRule (same IkeAssociation and group of peers) is the object
of
two different sets of TimePeriod policies leading to create two
differents
IkeRule instances while the RuleTimePeriodSet could be updated.

Thanks for your comments.

Pierrick Morand
france telecom R&D/DMI/SIR/IPI
Tel   : +33 2 31 75 91 79 -  Fax : +33 2 31 73 56 26
Email :[email-masked]