Re: IPSP policy model: contidtions and actions

["Lee Rafalow" <rafalow@xxxxxxxxxxxxxxx>]

Ricky, et al,

At the Policy Framework meeting on Wednesday, a small team of a subset of
the authors of the various drafts was formed to examine the differences
between the various drafts and propose a convergence or an explanation for
differences.  Packet classification is certainly one of the areas and in a
couple of ad hoc meetings we have already made some progress toward a common
understanding of the some of the differences.

First, as I mentioned in my talk, the background on the difference in packet
classification has to do with the level of abstraction of the domain-level
and device-level models.  As I mentioned in my response to Jean last week,
we haven't really discussed the relative merits of having the models close
to their target implementations vs. having the models close to each other.
Right now, the two device-level models both use filters (tho there are some
differences there as well, imo, caused by the need for compromises among the
QDDIM draft authors).

The more general technique of using a <variable><operator><value> grammar
(aka "atoms") is appealing even though it can be more verbose than the
filters approach.  Right now, that grammar has only one operator defined,
match, that compares a packet variable with a value or a set of values.  In
ICIM, we have a term of the condition specified by the AcceptCredentialsFrom
association to CredentialManagementService(s) and their trust hierarchies.
To do this with the atoms approach is not a simple extension.  The typing of
the association between the condition and variable would be extended to
include objects, similarly for condition and value.  Further, the use of an
enumeration to specify the operation needs to be examined: perhaps there's a
match method that is redefined in subclasses as needed.  We're looking at
these questions.

Of course, a simpler approach to convergence here would be to use atoms as
is for those things that can be specified with them and use other techniques
(e.g., AcceptCredentialsFrom) as needed.

Regardless, for IPsec to use the atoms technique, we would need to define
subclasses of variable and value for things like ID payloads and credential
fields.

Thoughts?  Lee

----- Original Message -----
From: "Ricky Charlet" <rcharlet@xxxxxxxxxxxx>
To: ""ipsec-policy@xxxxxxxx, Ricky Charlet"" <"ipsec-policy@xxxxxxxx, Ricky
Charlet":@ns.secondary.com;@rtpmail02.raleigh.ibm.com;>
Sent: Wednesday, December 13, 2000 5:12 PM
Subject: IPSP policy model: contidtions and actions


> Howdy,
>
> I think that the IPSP policy model puts conditions in the wrong place.
> SAConditions are contained by SARules which are derived from the Policy
> Core Information Model's Policy Rule. The problem I see here is that
> SAConditions are too specific to IPsec. I would rather see a model which
> sets up generic conditions to classify packets. Once a packet is classify
> by generalized conditions, then various actions (ie. ipsec, qos, nat,...)
> could be applied in a list of actions.
>
> Now, to do this would require tremendous coordination between all groups
> who might have an interest in packet classification. We know that right
> now, the qos and ipsec ways of modeling conditions or filters or are
> disjoint. So I am making a recommendation which will require a good bit of
> cross WG work and might perhaps move slowly.
>
> So what would be the benefit?
>
> If current trends hold, and each group who has an interest in classifying
> packets develops its own classification method, then we are very close to
> requiring that unnecessarily repetitive classification operations be done
> for each action which should be applied to the packet. It should be easy
> for us to envision examples where several actions (ipsec, qos, nat,
> firewall, ...) should be applied to the same packet. We should obviously
> strive to classify the packet once in implementations.
>
> Now, I said  ' very close to requiring' . I guess that even if different
> groups do invent different models of how to do classification, that does
> not necessarily mean that implementations must actually do classifications
> differently. But it certainly would be a confusion situation.
>
> Ricky Charlet
> rcharlet@xxxxxxxxxxxx
>