Subject: RE: policyValidityPeriodCondition

From: "Hugh F. Mahon" <[email-masked]>
Date: Tue, 23 Feb 1999 13:00:35 MST

Hi Folks,

        There seem to be concerns about the use of 
policyValidityPeriodCondition (PVPC), and there is a desire to treat 
the PVPC as a special case (have it evaluated separately from other 
conditions).

        I am interested in understanding the concerns, but so far have 
only heard/seen suggestions on how to address the concerns.

        Here is how I view the use of PVPC.  PVPC is just another 
condition.  We have two ways of organizing conditions, DNF and CNF.  
These provide the ability to handle very diverse logical expressions.

        If an administrator wished to have multiple valid periods with 
other conditions which will be the same for all validity periods then 
CNF provides for this.  For example:

        ((PVPC1 || PVPC2 || PVPC2) && (cond1) && (cond2) && (cond3))

        The above is a degenerate case since each of the conditions 
between ANDs (&&) could contain multiple conditions ORd together (as 
are the PVPCs in the first condition expression above).

        If an administrator wished to have separate conditions for a 
given validity period, DNF successfully allows this, for example:

        ((PVPC1 && cond1 && cond2) || (PVPC2 && cond3 && cond4) ... )

        One concern I believe I have heard is that the validity period 
is used to determine before hand what rules will be in effect.  I agree 
with this but do not see why it requires that PVPC be evaluated 
at the rule level separately from other conditions.  Whether PVPC is 
within the other conditions or at the rule level the entity evaluating 
policy must evaluate PVPC information.  It seems like an implementation 
detail for optimization, not a necessity for data organization for 
specific condition type representation ordering.  The fact that time, as 
expressed using PVPC, is something that we can all envision being used 
in any type of policy seems to be its only special property.

        Thanks,

        Hugh Mahon                              |__|     
        Hewlett-Packard Company                 |  |     
        e-mail: [email-masked]                  |\  /|
        Phone: (970) 898-BITS (898-2487)           | \/ |

---

From: John Schnizlein <[email-masked]>
Date: Tue, 23 Feb 1999 17:26:37 -0500

>only heard/seen suggestions on how to address the concerns.

One of the points made in the discussion last week, but not pursued, was 
that the condition clause is built from (at least) 2 very different kinds 
of conditions: the characteristics of the data stream and the state of the
network and policy system. A typical QoS policy might be constructed as
if (protocol is http AND server is bookingOrders) then (highest priority),
but PVPC is derived from the time of day and schedule rules.
DebugMode is another condition not reflected in the content of a packet.
I can imagine conditions that are hybrids: DHCP state combines with the
contents of the packet for a condition of (user is John).
Some distinction between the different kinds of conditions seems inherent,
but is not reflected in the general form of the condition -> action rules.
Should it be? We all expect it will be in the implementation.

John

---

From: "Hugh F. Mahon" <[email-masked]>
Date: Wed, 24 Feb 1999 0:31:48 MST

Hi John,

        Thanks for the response.  I think I understand the concern 
now.  I do think there are multiple ways of solving the problem, and 
each solution has its own set advantages and disadvantages.  If the 
text below doesn't sound like I have understood let me know. 

> Should it be? We all expect it will be in the implementation.

You point out that there are different types of conditions for 
different applications of policy.  For these different applications, 
there are some kinds of conditions that are more important than 
others.  Agreed.

The purpose of this schema we are defining is for the general case, 
and we have also defined how the classes in the schema can be derived 
from for more specific uses of policy.  One of the optimizations 
already described is that of allowing purpose specific condition types 
to be associated as part of the Rule itself, rather than in a separate 
association for more general conditions.  This does not prohibit the 
use of specialized derivations of policyRule, but also does not force 
a data organization that is not optimal for other uses of policy.

I think it is perfectly valid for an administrator to want to write a 
rule which may have multiple PVPs, each of which may have different 
conditions associated with it.  Having a (set of?) PVP(s) associated 
with the policyRule does not make sense for this case.  

Proposed solution: PVP is still a condition that is associated with 
the policyRule via the policyRuleConditionList, and specifically state 
in the draft that for instances of policy which require time to be 
evaluated earlier than other conditions (and not in DNF) that a 
derived class of policyRule shall be created which contains a PVP.  
Also note that by extension to this method, any other specialized 
class of policyRule may be created which may have other specific 
condition types within the rule, also to aid in optimization of 
execution.

Would this address your concerns?  

What I am looking for is a way to address your concerns (making sure 
specific uses of policy can be optimized), yet permit a schema that is 
general in nature. 

> John

Hugh

---

From: Silvano Gai <[email-masked]>
Date: Wed, 24 Feb 1999 09:19:50 -0800

IMHO a policy rule must have three different conditions that apply in AND:

(PVPC) & (RoleCondition) & (PacketCondition)

each of the three may be a CNF/DNF.

PVPC gives the interval in which a policy applies;
RoleCondition associate the Policy with roles;

This first two conditions are evaluated by the PDP and select which rules must be downloaded to the PEP.

PacketCondition is a typical MFC and is applyed by the PEP.

I don't buy the argument: "the PacketCondition are in the action part of the rule".

-- Silvano

>Should it be? We all expect it will be in the implementation.

Silvano Gai               
Cisco Systems                  Empowering the Internet Generation
170 West Tasman Drive                         Tel. (408) 527 2690
San Jose, CA, 95134-1706                      Fax. (408) 526 2690
                                                   [email-masked]

---

From: "Hugh F. Mahon" <[email-masked]>
Date: Thu, 25 Feb 1999 0:05:41 MST

Hi Silvano,

> each of the three may be a CNF/DNF.

Is PacketCondition a requirement for security policy, too? 

> This first two conditions are evaluated by the PDP and select which rules must be downloaded to the PEP.

I think there are at least two things being discussed here.  One is 
data organization in the schema, the other is how the PEP uses the data.

I believe that the information that associates the policy data with 
the managed object is different from other the condition information. 

How the PDP evaluates the conditions is dependent on the 
implementation of the PDP.  (In other words, it is left to the 
implementation of the PDP how to optimize, if at all, the handling of 
the conditions for the types of policies it supports.) 

For a policy with a PVP of 8:00 to 17:00, when does the PDP download 
the policy (from the directory) in order to know what and when to 
download information to the PEP (if, for example, it is configuring 
the PEP), or how to respond to a request from a PEP (if the PEP is 
asking the PDP for decisions)? 

> PacketCondition is a typical MFC and is applyed by the PEP.

I'm afraid I'm unfamiliar with MFC in this context.  What is MFC?

> I don't buy the argument: "the PacketCondition are in the action part of the rule".

I don't know what that means either.  I think that there are actions 
and conditions, and that the execution of the actions is dependent on 
the evaluation of the conditions.  I see them as two distinct parts of 
a policyRule.

Do we agree on the above paragraph?

Hugh

---

From: Silvano Gai <[email-masked]>
Date: Fri, 26 Feb 1999 08:32:43 -0800

>Is PacketCondition a requirement for security policy, too? 

YES, Firewall are devices that test the PacketConditions.

>asking the PDP for decisions)? 

I think that PDP download from the Directory the Policy for all the PVP and then, depending on the time of the day, select the subset to be dowloaded to the PEP.

>I'm afraid I'm unfamiliar with MFC in this context.  What is MFC?

MFC is Multi Field Classifier, the standard term for an Access Control List.

>the evaluation of the conditions.  I see them as two distinct parts of 

I have seen the following example:

if (user = john) then 
   $ipaddr = DHCP_lookup(user = john); 
   configure_classifier (device = $device, source = $ipaddr/32, 
                         protocol = "http", mark = DSCP(8));

In this example the condition when matched causes the downloading of a MFC on the PEP which is a PacketCondition. Therefore, in this case, the PacketCondition is in the action part of the rule.

>Do we agree on the above paragraph?

I would like to have the PacketCondition be part of the rule condition.

-- Silvano

Silvano Gai

---

From: "Hugh F. Mahon" <[email-masked]>
Date: Fri, 26 Feb 1999 11:07:14 MST

Hi Silvano,

        Thanks for the reply.  I think we are very close to agreement.

> I think that PDP download from the Directory the Policy for all the 
> PVP and then, depending on the time of the day, select the subset to 
> be dowloaded to the PEP. 

It sounds like we are very close to agreeing!

> In this example the condition when matched causes the downloading of 
> a MFC on the PEP which is a PacketCondition. Therefore, in this case, 
> the PacketCondition is in the action part of the rule.  
> 

O.k., tell me if I've got this right.  In the above example, the 
condition seems to be 

        (user = john)

If this condition evaluates true, the other actions occur.  The MFC is 
the condition '(user = john)'?  If this is what you mean, then isn't 
PacketCondition a specialized case of condition?

We have not yet specified what the conditions are to be.  We have 
defined that a rule contains multiple kinds of information.  One is an 
association which refers to one or more actions.  Another is an 
association with one or more conditions, and the conditions may be 
organized in CNF or DNF depending on the needs of the policy author in 
order to express the boolean statement for the particular situation.

We have a base class for a condition, and we have one derivation for 
it currently (policyValidityPeriod), and expect to define others in a 
standard at some point, and to have implementors define yet others as 
the need arises (hopefully those will be standardized at some point, 
too).

We have also defined how an implementor may include specific 
conditions directly in the policyRule object in order to allow 
optimization for particular needs.

Based on the above, I think PacketCondition is derived from the 
generic condition class as currently defined.  For implementations 
that require processing optimization for data retrieval from LDAP 
servers the PacketCondition could be contained directly within the 
PolicyRule if so desired (a derived class from policyRule) rather than 
in a generic list of conditions.  (I have concerns about this for 
interoperability reasons, but such optimization considerations have 
been discussed and I am interested in learning how other people feel 
about them and where the Working Group goes with them.)

In a shorter form: I agree that PacketCondition is part of the 
condition portion of the rule.  I see it as a specific instance of a 
condition, not separate from the already stated concept of condition. 

For a document which is focused on the schema for policy 
PacketCondition is an example of a condition, and could be called out 
as such.  PacketCondition should be specified as part of a paper 
describing specifically how policy is used for network management.

To try to elaborate further, for the general case we can all envision 
the use of time as a condition for policy no matter what the policy is 
being applied to.  PacketCondition is something that would be a 
pre-requesite for any policy operations dealing with network 
operations.  So far we have been dealing with the general case.  
Specifying PacketCondition could be done now, but it a different 
document than the schema document.

> San Jose, CA, 95134-1706                      Fax. (408) 526 2690

Sorry for the verboseness.  I think we are close to agreeing, but are 
using different terminology which causes confusion.  I look forward to 
your questions and other feedback.

        Hugh Mahon                              |__|

---

From: Silvano Gai <[email-masked]>
Date: Fri, 26 Feb 1999 12:05:09 -0800

see inline

>PacketCondition a specialized case of condition?

No the MFC is: 
                           (device = $device, source = $ipaddr/32, 
                            protocol = "http", mark = DSCP(8))

and it is in the action part of the rule.

-- Silvano

Silvano Gai

---

From: "Hugh F. Mahon" <[email-masked]>
Date: Fri, 26 Feb 1999 14:50:14 MST

Hi Silvano,

> and it is in the action part of the rule.

Do you mean you are testing for equality?  If so, why is this a 
condition in the action portion?  Or are you trying to specify another 
policy that is in the action (i.e., nested policies)?  So, given the 

> >>                          protocol = "http", mark = DSCP(8));

Is a portion of the above example an action that is not testing 
conditions?  If this is not a complete example with both actions and 
conditions, please provide complete example to illustrate your point.  
I am just trying to understand what you want.

An example of what I am looking for is:

     rule: 
             action: Mark packet with DSCP(8)
             condition: (srcIPaddr == 192.168.0.3) or 
                        ((srcsubnet == 192.175.0.0/16) and (protocol == HTTP))

Hmmm.  Maybe I am beginning to understand.  Do you see the action 
portion as what is configured on the device (and not the condition)?  
I see BOTH the condition and the action as being configured on the 
device.  How the condition and action get translated into device 
configuration is implementation dependent.  

So, based on the above, I would write something like the following:

    Rule:
        action: mark packet with DSCP(8)
        condition: ((user == john) and (ipaddr == DHCP_addr(john)) and 
                    (protocol == http))

If you want an action that specifies the configuration of the device 
the way you specified in the first example above, then PacketCondition 
becomes a derivation of action that is specific to policies for 
networking.

Is this addressing your concerns?  If not, help me to understand why 
not.

Thanks,

Hugh

---

From: Silvano Gai <[email-masked]>
Date: Tue, 02 Mar 1999 11:06:01 -0800

Hi Hugh,

let me restart from scratch.

A policy rule is of the form:

             if condition then action

I think there is agreement that:
- time of the day is a condition
- dropping is an action
- marking is an action
- role is a condition

I don't think we have agreement on what are: 
-  Classifiers. i.e. an entity which selects packets based on the content of
   packet headers according to defined rules. In particular:
   - MFC (Multi Field Classifier)
   - BAC (Behavioral Aggregate Classifier)
-  Traffic Conditioner, i.e. an entity that performs traffic conditioning
   functions and which MAY contain meters, policers, shapers, and
   markers.  

I think there is agreement that the classifiers and traffic conditioner must run on the network device.

Classifiers and Traffic Conditioners need to take action based on packet, e.g.
- a BAC tests if DSCP == 8 then ...
- a MFC tests if IPSA = 130.192.1.1 || IPDA == 1.1.1.1  then ...
- a traffic conditioner test if PeakRate > 1 Mb/s then ...

At this point my question is: do we agree that "DSCP == 8", "IPSA = 130.192.1.1 || IPDA == 1.1.1.1", "PeakRate > 1 Mb/s" are conditions?

Do we agree that being conditions they must show up in the condition part of a policy rule?

If we agree on this, then the function of the PDP becomes a "policy filtering function": the PDP reads all the policies from the directory and download them to the PEP after making a selection based on time of the day and roles. The evaluation of the policies is delegated to the PEP.

Therefore I propose a structure like:

rule :== if condition then action

condition :== [PVPC] [RoleCondition] [PacketCondition]

action :== drop | mark |  ...

PVPC            evaluated by the PDP 
RoleCondition   evaluated by the PDP
PacketCondition evaluated by the PEP

If we agree on this we can start our discussion on rule evaluation, conflict detection and conflict resolution.

Thank for reading all this

-- Silvano

Silvano Gai

---

From: Raju Rajan <[email-masked]>
Date: Tue, 02 Mar 1999 18:06:25 +0000

> - time of the day is a condition

Silvano

I dont understand the interaction between the two ways of dealing with
"role" that you have suggested
(a) as part of the traffic condition,
(b) using policy grouping objects.

Since, we are grouping policies, and we may just as well group them by
the role, can you tell me why we need to come up with role based
condition objects as well?

> I don't think we have agreement on what are:
...
> Do we agree that being conditions they must show up in the condition part of a policy rule?

Peak rate is not a well defined entity. When you talk about
deterministic rates you must talk about the interval of time you're
averaging over and the burst sizes that are allowed. Different standards
and services measure it differently -- ATM has a leaky bucket model
(GCRA?), the Intserv Guaranteed Service specs define it one way, and
Controlled load has a looser definition of rate. And all this is just
deterministic rates. You may measure rates with reference to stochastic
models and confidence intervals as well.

My point is that not everything that can occur as a conditional clause
in a IF ... THEN ... statement needs to be represented in the policy
condition object class. I would suggest that we use 2 criteria

a) Is this condition clearly defined ?
So a clause like
  If the network is uncongested then ...
would not be allowed. Rates are service specific and fall in the grey
area, so I would prefer that we deal with them later.

b) Is this condition useful for multiple action classes?
So a rule  such as
[If the number of RSVP controlled load connections smaller than 10MBps
is greater than 50 then don't allow the next connection. ]
may not be represented in the above form as If condition then action.
What we can do is rephrase this as
 If RSVP request then (if the number of controlled load connections is
... then dont allow the next connection).
                      or equivalently
If RSVP request then (max # 10 MBps connections = 50)

Thus, a portion of the conditional clause moves into the action, because
it is not relevant to different actions we are defining.

At least initially, I'd suggest that we stick to hosts, users,
applications, routing info and layer 2 info as conditionals, and then
expand into everything else.

I agree that 

rule :== if condition then action
condition :== [PVPC] [PacketCondition]
packetCondition := [User/Host/Application/Routing/Layer2 Condition]

Regards,

Raju Rajan

---

From: Silvano Gai <[email-masked]>
Date: Tue, 02 Mar 1999 15:49:55 -0800

>condition objects as well?

I think that we can use policy groups to represent roles. Policy Groups are a way to select a group of policies that apply somewhere. Roles are a way of requesting a group of policy, may be the role is an attribute of the policy group. Anyhow I think we agree that role/policy group are used to select which policies to apply on a given interface/device/etc.

>> At this point my question is: do we agree that "DSCP == 8", "IPSA = 
>130.192.1.1 || IPDA == 1.1.1.1", "PeakRate > 1 Mb/s" are conditions?
>> 

I completely agree, but this was just an example. Select you preferred Traffic Conditioner and choose a real parameter or set of parameters.

>area, so I would prefer that we deal with them later.
I agree, I don't see how we can support something not well defined :-)
But there are traffic conditioner well defined and you can execute them only on the PEP, do you agree?

>packetCondition := [User/Host/Application/Routing/Layer2 Condition]

If you replace role with policy group, it is fine, we agree.

Do you agree that:

<user> :== <IP address>
<host> :== <IP address>
<application> :== <protocol> [<source-port>] [<destination-port>]
<protocol> :== TCP | UDP

Routing I don't know, what do you mean?

<layer 2 condition> :== [<test on MAC SA>] [<test on MAC DA>]

???

-- Silvano

>
>Regards,
>
>Raju Rajan
>
>> 
>> If we agree on this, then the function of the PDP becomes a "policy 
>filtering function": the PDP reads all the policies from the directory and 
>download them to the PEP after making a selection based on time of the day 
>and roles. The evaluation of the policies is delegated to the PEP.
>
>
>
>> 
>> If we agree on this we can start our discussion on rule evaluation, 
>conflict detection and conflict resolution.
>> 

Silvano Gai

---

From: "Hugh F. Mahon" <[email-masked]>
Date: Sun, 07 Mar 1999 18:57:44 MST

Hi Silvano and Raju,

        A good discussion about hte components of a policyRule.

> - time of the day is a condition

Agreed so far.

> - role is a condition

Big concern here.

If 'role' is the identifier of where the policy is to be used, and the 
only component which can evaluate 'role' is the PDP, this implies to me 
that the PDP must first download ALL policyRules stored in the 
directory in order to understand which of those policies are to be 
used.  This seems impractical.  The role should be somewhere else to 
allow more economical determinism of which policies need to be 
retrieved from the directory. 

Thanks, Raju, for asking about 'role' as part of a group.  

> must run on the network device.

Does this really make a difference with respect to a general definition 
of policy?  I think it affects what is contained within the policy (the 
specific kinds of conditions and actions), but WHERE the policy is to 
be executed does not affect the form of the rule itself.

> filtering function": the PDP reads all the policies from the directory 
> and download them to the PEP after making a selection based on time of 
> the day and roles. The evaluation of the policies is delegated to the PEP.

I agree with the function of filtering and translation.  I think this 
is different than the definition as used in the RAP group, but not 
incompatible.  

...

Hugh