Subject: IPSEC PIB - Clarification request

From: MORAND Pierrick FTRD/DMI/CAE <[email-masked]>
Date: Mon, 19 Feb 2001 11:30:30 +0100

In the last version of the IPSec PIB document (version 01) some aspects of
the current PIB definition lead me to ask for some clarification.

1-An IpSecRuleEntry can reference a group of actions. These actions are
applied to the set of flows described by the set of IpSecSelectorEntries
attached to the rule.

a) can someone give examples of multiple actions that can be applied to the
same flows ? It seems that section 4.3 introduces this aspect but the
example starts introducing an exchange between two hosts A et B and a third
one C appears as if A had to communicate with C. In this example I
personally understand that the document attempts to say that a single rule
should be able to specify that traffic between A and B should be handle in
transport mode and a tunnel should be setup to handle traffic exchanged
between A and B thanks to the tunnel between A and gateway C. It seems this
should lead to the definition of 2 rules, each of them referencing a
different action (transport mode for one and tunnel mode for the other).

b) in case several actions are attached to an IpSecRule does this mean that
they shall all be applied in sequence according to their order or shall we
understand that once an action has been achieved the rest of actions will
not be considered ?

c) in case traffic shall be discarded or bypassed, it is written in the
description part of ipSecActionActionGroupId (page 20), that this last
attribute must be set to zero. In this case if one rule says that traffic
between A and B shall be discarded WITH NO logging and an other rule says
that traffic between C and D shall be discarded WITH logging this will lead
to create two ipSecActionEntries with GroupId set to zero. One will say
discard and no logging, the other will say discard and logging. If these
actions are attached to 2 different rules the corresponding action will
referenced an ipSecRuleIpSecActionGroupId of zero value that references
these two actions which are opposite. How will the system react ?

2-My understanding of IKE is that IKE phase 1 an 2 are triggered by IPSec.
It seems in the document that Ike Rules can be established independently of
IPsec Rules. Does this means that other protocols than IPSec are today able
to make use of IKE ? If so, wouldn't this lead to the definition of a stand
alone IKE PIB ? The current definition allows to create a RuleEntry with a
role combination and constraints and ipSecRuleEntry to reference and IKE
Rule having the same rule combination. Isn't there here is a duplicated
information ?

Thanks a lot for clarifying these points with my apologizes if my
understanding was incorrect partly due to the fact I am not an IpSec expert
at all.

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]

---

From: [email-masked]
Date: Mon, 19 Feb 2001 10:17:14 -0600

Hi Pierrick,

Thank you for reading the draft and for your comments. Please see my
comments below. The next version will clarify these points.

Man Li
Nokia 
5 Wayside Road, Burlington, MA 01803
[email-masked]
phone 1-781-993-3923
GSM 1-781-492-2850 

-----Original Message-----
From: ext MORAND Pierrick FTRD/DMI/CAE
[mailto:[email-masked]]
Sent: Monday, February 19, 2001 5:31 AM
To: IPSEC-POLICY (E-mail)
Subject: IPSEC PIB - Clarification request

From A's point of view, there are two actions that need to be taken in
sequence. Hence the PIB downloaded to A will include a group of actions.

All of them should be applied in sequence.

Good point! The restriction "When ipSecActionAction is bypass or discard,
this attribute must be zero" should be removed. The description of the Order
attribute needs corresponding modification.

There are three scenarios to be addressed. 

- IPsec policy controls both IKE phase 1 and 2 negotiation.
- IPsec policy controls only IKE phase 1 negotiation. 
- IPsec policy controls only IKE phase 2 negotiation.  

In order to address the last two scenarios, both IPsecRule and IKERule have
role combinations. For the first scenario, the requirement for IPsecRule and
IKERule to have the same role combination is to ensure the consistency. It
may be easier for IPsecRule to simply reference an IKERule without
concerning the role combination of IKERule. We need to think a bit more on
this.