frameworkpib & access-bind: filters

[Freek Dijkstra <freek@macfreek.nl>]

Hi,

I've got another, more technical problem, which basically boils down to
the question how to specify wildcards in filters, like the ones defined in
draft-ietf-rap-frameworkpib-09.txt.


The issue merely applies to the Access Bind PIB
(draft-ietf-rap-access-bind-01.txt), in case there will be a new revision,
but maybe it's an interesting thought for PIB authors designing filters,
like the ones in the frameworkpib.


The current revision of the Access Bind PIB,
draft-ietf-rap-access-bind-01.txt, uses scopes, which are classes which,
among other things, specify a filter. They do that by including an
attribute called eventHdlrEventScopeFilter in these scope classes. This
ScopeFilter is a PRID pointing to some Filter Instance, for example one of
the filters defined in in draft-ietf-rap-frameworkpib-09.txt. (See
Background bellow for a one alinea introduction to the Access Bind PIB)

Now, this scope is not only used to filter data traffic, used also use to
trigger certain events. For example, you can specify that each data filter
that matches the filter also triggers a certain event. However, in most
cases, you don't want to trigger for each event, but only for the first
data packet coming from an unknown source. So for example, you may want to
say "allow traffic coming from source IP address in the range 10.0.0.0 to
10.0.255.225, and generate an event every time you see a new IP address".

This can be done by specifying a filter, in particular a filter of type
frwkIpFilter. This can be done. However, the frwkIpFilter also specifies
other fields to filter on, like destination IP address and source- and
destination port. I want to be able to say 'ignore the port field'. If I
don't say that, the PEP will not only trigger an event for each new source
IP address it encounters, but for each different port it encounters as
well. So we are tempted to specify in the Access Pind PIB to say 'ignore
every field that is a wildcard'.

However, this is not entirely correct. For example, we may want to say
allow any source IP address (don't filter on that, but do trigger on it),
and allow any destination port (don't filter on that, and neither trigger
on it).

So we want to make a difference between:
- Filter on it, and trigger on it
- Don't filter on it, and trigger on it
- Don't filter on it, and don't trigger on it
(the fourth option, filter on it, but don't trigger on it is already dealt
with, using an atttribute called eventHdlrEventScopeChangeFlag. The exact
solution is out of scope of this e-mail).

The last two options can be rephrased into my main question:
  Given a filter, can I distinguish between "ignore a field" and "don't
  ignore a field, but match every possible value"?

For most filtering purposes, this seem to boil down to the same thing
(i.e. wildcard that field).  However, I hope I showed you that for the
Access Bind PIB, these two things are not the same.

I would be pleased if someone could at least answer this question for the
frwkIpFilter class. A problem I encountered is that all the Framework PIB
says about wildcards is: "Wildcards may be specified for those fields that
are not relevant." However, it is not clear HOW such a wildcard should be
specified (perhaps using the value 0?). The document does talk about
wildcards for Roles, but that doesn't seem to apply to the filter classes
in the PIB in chapter 5.



Background:

People not familiar with the Access Bind PIB, but familiar with the
DiffServ model: just think of the Access Bind PIB as a PIB defining a
Classifier, albeit a very rather complex one. The complexity comes from
the fact that it can not only filter data traffic to decide what the next
datapath (DiffServ)  element is, but it can also communicate with the PDP
in order to authenticate a data stream.


Regards,
Freek Dijkstra