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

From: "Khosravi, Hormuzd M" <[email-masked]>
Date: Sun, 23 May 2004 20:40:29 -0700

Thanks Weiming, for your reply. This is helpful since I am writing up
the Config msg.
 
regards
Hormuzd

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Wang,Weiming
Sent: Sunday, May 23, 2004 8:29 PM
To: [email-masked]
Subject: Re: [Forces-protocol] Summary of Protocol Messages (Command
Types)

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

From: Khosravi, Hormuzd M <mailto:[email-masked]>  
To: Robert Haas <mailto:[email-masked]>  ; Wang,Weiming
<mailto:[email-masked]>  
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.

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 12:13:12 +0800

MessageHi Hormuzd,

One more thing is about the TfLV.  I agree that some flags related to atomic ops can be as flags. The only thing is, I think atomic ops will mainly happens in config msgs. (though not very sure). therefore, in the msgs that i'm to put, the flags still have not been considered. But I think it can be modified easily later if needed.

Cheers,
Weiming

  ----- Original Message ----- 
  From: Khosravi, Hormuzd M 
  To: Wang,Weiming ; [email-masked] 
  Sent: Monday, May 24, 2004 11:40 AM
  Subject: RE: [Forces-protocol] Summary of Protocol Messages (Command Types)

  Thanks Weiming, for your reply. This is helpful since I am writing up the Config msg.

  regards
  Hormuzd
    -----Original Message-----
    From: [email-masked] [mailto:[email-masked]] On Behalf Of Wang,Weiming
    Sent: Sunday, May 23, 2004 8:29 PM
    To: [email-masked]
    Subject: Re: [Forces-protocol] Summary of Protocol Messages (Command Types)

    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