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

From: "Khosravi, Hormuzd M" <[email-masked]>
Date: Fri, 21 May 2004 15:50:03 -0700

Hi Robert,
 
The basic reason for having an Event Msg is to report Asynchronous
events from FE -> CE. We extended this use to accommodate
Subscribe/Unsubscribe functions based on Your and Weiming's preferences.
It seems like you are having different thoughts on this now, which is
fine. I think you would like is to have Subscribe/Unsubscribe as part of
Config rather than Event msg. This is fine by me, and I think Weiming
will also be fine to accommodate this since this was one of the options
that he had stated before. 
 
Weiming, let us know what you think about this ? If we go with this
approach, we will probably not need Response for Event msgs.
 
Thanks
Hormuzd

-----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.

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

---

From: "Wang,Weiming" <[email-masked]>
Date: Mon, 24 May 2004 11:28:47 +0800

MessageHi Hormuzd, Robert, and all,

Sorry reply to you very late, for I was very busy last weekdays for univ. business and busy writing my draft part during the weekend. 

I agree to let config msg do the sub/unsub of events. Actually in this case, the 'EventConfg' as I mentioned ealier can also be put in the 'Config' msg, leaving the event msg only for 'event report' and 'event response'. I think event response as a message should be put there, whether customers use it will be decided by the Response flag in the header. 

Thank you.
Weiming

----- Original Message ----- 
  From: Khosravi, Hormuzd M 
  To: Robert Haas ; Wang,Weiming 
  Cc: [email-masked] 
  Sent: Saturday, May 22, 2004 6:50 AM
  Subject: RE: [Forces-protocol] Summary of Protocol Messages (Command Types)

  Hi Robert,

  The basic reason for having an Event Msg is to report Asynchronous events from FE -> CE. We extended this use to accommodate Subscribe/Unsubscribe functions based on Your and Weiming's preferences. It seems like you are having different thoughts on this now, which is fine. I think you would like is to have Subscribe/Unsubscribe as part of Config rather than Event msg. This is fine by me, and I think Weiming will also be fine to accommodate this since this was one of the options that he had stated before. 

  Weiming, let us know what you think about this ? If we go with this approach, we will probably not need Response for Event msgs.

  Thanks
  Hormuzd
    -----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.

        [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. 

    Regards,
    -Robert

---

From: Robert Haas <[email-masked]>
Date: Mon, 24 May 2004 10:05:58 +0200

Hi Weiming,
I think we achieve indeed a cleaner design by merging the "Config" and 
"Event" message types, so that actions of those types can be placed in 
the same PL message.

Now, for the EventResponse, I am not sure whether this should be a 
message of its own, or be merged into the ConfigResponse as well for 
consistency. What is the reason you think we should have a separate 
ConfigResponse ?

But I understand that EventReport should be a separate message.

Regards,
-Robert

Wang,Weiming wrote:

> Hi Hormuzd, Robert, and all,
>  
> Sorry reply to you very late, for I was very busy last weekdays for 
> univ. business and busy writing my draft part during the weekend.
>  
> I agree to let config msg do the sub/unsub of events. Actually in this 
> case, the 'EventConfg' as I mentioned ealier can also be put in the 
> 'Config' msg, leaving the event msg only for 'event report' and 'event 
> response'. I think event response as a message should be put there, 
> whether customers use it will be decided by the Response flag in the 
> header.
>  
> Thank you.
> Weiming
>  
>     From: Khosravi, Hormuzd M <mailto:[email-masked]>
>     To: Robert Haas <mailto:[email-masked]> ; Wang,Weiming
>     <mailto:[email-masked]>
>     Cc: [email-masked] <mailto:[email-masked]>
>     Subscribe/Unsubscribe functions based on Your and Weiming's
>     preferences. It seems like you are having different thoughts on
>     this now, which is fine. I think you would like is to have
>     Subscribe/Unsubscribe as part of Config rather than Event msg.
>     This is fine by me, and I think Weiming will also be fine to
>     accommodate this since this was one of the options that he had
>     stated before.
>      
>     Weiming, let us know what you think about this ? If we go with
>     this approach, we will probably not need Response for Event msgs.
>      
>     Thanks
>     Hormuzd
>
>>             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.
>

-- 
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

---

From: "Wang,Weiming" <[email-masked]>
Date: Mon, 24 May 2004 16:26:38 +0800

Hi Robert,

My thought of the use for EventResponse is,  for some of the events, the sender (say FE) may very much care if the receiver (CE) has received the info for it thinks  the event info is vital. In this case, a response acting as an acknowledge is useful. Note that, our current scheme has incorparated the ACK in the responses, that means we will not have other means to ACK the event transport if we do not define a response for it. Of course, a user still can have the flexibility by using the ACK flag in the header not to ask the response.  Therefore, I just think it may inhance the flexibility anyway.

Thank you.
Weiming
  ----- Original Message ----- 
  From: Robert Haas 
  To: Wang,Weiming 
  Cc: [email-masked] 
  Sent: Monday, May 24, 2004 4:05 PM
  Subject: Re: [Forces-protocol] Summary of Protocol Messages (Command Types)

  Hi Weiming,
  I think we achieve indeed a cleaner design by merging the "Config" and "Event" message types, so that actions of those types can be placed in the same PL message.

  Now, for the EventResponse, I am not sure whether this should be a message of its own, or be merged into the ConfigResponse as well for consistency. What is the reason you think we should have a separate ConfigResponse ?

  Regards,
  -Robert

  Wang,Weiming wrote:

    Thank you.
    Weiming

    ----- Original Message ----- 
      From: Khosravi, Hormuzd M 
      To: Robert Haas ; Wang,Weiming 
      Cc: [email-masked] 
      Sent: Saturday, May 22, 2004 6:50 AM
      Subject: RE: [Forces-protocol] Summary of Protocol Messages (Command Types)

      Hi Robert,

      Thanks
      Hormuzd
        -----Original Message-----

        Regards,
        -Robert