Subject: RE: On policy conditions

From: "Black, David" <[email-masked]>
Date: Fri, 23 Apr 1999 16:49:08 -0400

> Unless we are defining the ability for the PDP/PEP pair to spontaneously
> create information as a result of policy and internal stimulus (as in the
> backup example), then the only time that policy and instrumentation needs
to
> be examined is coincident with a packet arrival. It is the unit of work.
All
> transitions of any consequence originate with the arrival of a unit of
work.
> The instrumentation needs to be able to classify the content of the unit
of
> work, extract meaning, modify state and decide if a policy rule requires
> examination.

This is ok until one makes the jump to assuming that there is exactly one
type of instrumentation and hence one logical definition of packet arrival.
It is necessary to be able to insert instrumentation wherever it makes
sense, and instrumentation code at the IP level cannot "classify" or
"extract
meaning" from things that are inherently opaque at that level.  The
"10th premium user logged on" case is one example because IP level
monitoring code cannot determine whether the logon succeeded or whether
the user is a premium user.  Another example is management policy for
dealing with IPsec security violations -- one cannot determine whether
an arrived packet constitutes a security violation without doing the
IPsec processing first.

The examples so far, require the following classes of events:
	- Packet arrival (presumably based on MF or BA classifier)
	- Logon (based on instrumenting logon events)
	- Time (based on some notion of network time)
And I've just added another one:
	- Security (based on monitoring audit events from IPsec or the like)
The first moral to be drawn from this is that the event class mechanism
has to be extensible.

Just to reiterate the major point -- while both
the Logon and Security event classes are "coincident with a packet
arrival", they are not "Packet arrival" events because it is impossible
for MF or BA classifier code (or anything else that only looks at the
packet) to extract the required meaning from the packet.  Instead external
state is required (e.g., the Logon event class needs to know the user's
password in some form) and the instrumentation that declares events to
policy needs to be attached to code that already understands how to
interact with the required external state.

Silvano writes:

> IF "user John is logged on" THEN
> 
> where is the handler that set/reset the state "user John is logged on"?
> 
> As David mentioned, the handler cannot be associated with the arrival of
the logon or logoff > packets, but must take into account the execution of a
login/logout procedure that could be
> quite complex.
> 
> I think we should introduce in the PDPs the concept of "explicit event
handlers". An Event
> handler is a procedure to map event/transitions into states. I also think
we should
> write the policies only in term of states and packet conditions.

I agree with much of the overall approach, but disagree with requiring a
conversion from
the event "John has logged on" to the state "John is logged on".  The policy
system ought
to be able to deal with the former type of event without having to maintain
the latter
form of persistent state (the logon system already tracks this - why does it
need to
be duplicated?).  I would modify Silvano's approach to have events be
accompanied by "parameters" (the "user" parameter whose value could be
"John" is one
such example).  The difference between "parameters" and "states" is that the
former
are private to the policy invocation caused by the event (e.g., two logon
events with
different values of "user" could be handled concurrently by the same policy
instance)
and are ephemeral in that they vanish when the policy invocation terminates,
whereas
the latter are global states visible to all invocations, and are persistent
in that
the persist in the PDP for future use.  The upshot is that what Silvano
calls "explicit
event handlers" I would refer to as "event glue code" that takes the event
in the
form that the instrumentation detected it and provides it to the policy
system in
the policy system's required format (with parameter values either extracted
from
the instrumentation or suitably defaulted) -- WARNING: the "policy system's
required
format" is essentially an API, which may well be outside the scope of what
is
reasonable to standardize here.

Returning to the parenthetical comment on logon state, there are actually 3
possibilities:
	- Policy maintains "logged in" state separate from logon code.
	- Policy has no notion of "logged in" state, but only event
parameters (e.g.,
		who has logged in).
	- Policy has access to the state maintained by logon code via a
suitable set
		of conditions.
Of these, I think the first one is not a particularly good idea, but the
other two are
reasonable (and the third one is an alternative answer to Silvano's question
in the form
that he asked it).

--David

---------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 42 South St., Hopkinton, MA  01748
+1 (508) 435-1000 x75140, FAX: +1 (508) 497-6909
[email-masked]
---------------------------------------------------

---

From: Silvano Gai <[email-masked]>
Date: Mon, 26 Apr 1999 17:21:05 -0700

At 04:49 PM 4/23/99 -0400, Black, David wrote:
> I would modify Silvano's approach to have events be

Parameters are fine, the "event glue code" may have parameters. The question is: does the PDP stores the fact that user John is logged on? or does the event glue code provides an API to read the fact that the user john, either is, or is not, logged on in the "login system"?

-- Silvano

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