Subject: RE: [Forces-protocol] Summary of Protocol Messages (Command Types)

From: "Khosravi, Hormuzd M" <[email-masked]>
Date: Wed, 19 May 2004 18:13:12 -0700

Hi Robert,

-----Original Message-----

Here is another example in which I think we may need to dynamically
subscribe to events:

The CE adds a filtering rule, and at the same time requires event to be
fired whenever a packet matches this rule. This can be for the purpose
of DoS detection, for instance.

Let me know if this is a convincing example. 
 
[HK] I don't think we will be subscribing to events at this level of
granularity. From my little experience at the NPF and what I have seen
from the Model team, events will be defined on per LFB basis. The
example that you have given here is a lot more granular, i.e. per entry
basis in a LFB table. I dont think this level of granularity will be
supported.

regards
Hormuzd

---

From: Robert Haas <[email-masked]>
Date: Fri, 21 May 2004 21:07:56 +0200

Hi Hormuzd (and others interested in the way events are supported in the 
protocol and model),

Khosravi, Hormuzd M wrote:

>     Here is another example in which I think we may need to
>     dynamically subscribe to events:
>
>     The CE adds a filtering rule, and at the same time requires event
>     to be fired whenever a packet matches this rule. This can be for
>     the purpose of DoS detection, for instance.
>
>     [HK] I don't think we will be subscribing to events at this level
>     of granularity. From my little experience at the NPF and what I
>     have seen from the Model team, events will be defined on per LFB
>     basis. The example that you have given here is a lot more
>     granular, i.e. per entry basis in a LFB table. I dont think this
>     level of granularity will be supported.
>
I won't argue against the fact that is is unscalable to let every 
firewalling rule fire up an event. Nevertheless, this can be useful for 
some of the firewalling rules (intrusion detection is another example).

I hope that the model will not only allow per-LFB events or I would 
consider this a bad design.  We should design our protocol so that it 
can be used in such cases (i.e., adding a rule and subscribing to an 
event of that rule).

I note that having a "Config" or "Event" message type in the common 
header forces us to send two separate messages to the same LFB. Not a 
great thing, especially since fundamentally, there is little value to 
separate the Config and Event types at the Common-Header level.

Maybe others have opinion on this too ?

Regards,
-Robert

-- 
Robert Haas
IBM Zurich Research Laboratory
Säumerstrasse 4
CH-8803 Rüschlikon/Switzerland
phone +41-1-724-8698  fax +41-1-724-8578  http://www.zurich.ibm.com/~rha