Subject: RE: [midcom] Latest requirements bullets resolved

From: "Tom-PT Taylor" <[email-masked]>
Date: Mon, 24 Sep 2001 11:32:46 -0400

At the very least one must speak of a security association between the
middlebox and the agent.  When you also talk about subscriptions to events,
it is clear that the relationship extend beyond security.  What has to be
meant by "session", therefore, is the entire control relationship between a
middlebox and a specific agent.

-----Original Message-----
From: Melinda Shore [mailto:[email-masked]]
Sent: Monday, September 24, 2001 10:24 AM
To: Mark Duffy; midcom
Subject: Re: [midcom] Latest requirements bullets resolved

At 09:35 AM 9/24/01 -0400, Mark Duffy wrote:
>Are we fixing it to clarify that these refer to the/a midcom
>session (I hope not) or to clarify that they refer to application sessions
>(microflows?) through  the middlebox?

Application sessions and "microflows" (still don't like that
term for our purposes) aren't the same thing.  We're trying
to get application involvement out of middleboxes.  Taking off
the chair hat for a moment, the way I see it the middlebox should
really only be notifying agents of events which affect that 
particular agent, whether it's a protocol failure of some sort,
reboot, etc.  I don't think that any notion of "session" we 
could come up with would be something that the middlebox ought
to tell the agent about.  My preference would be to drop the
two "session" events entirely and reorganize the sentence so
that it make it clearer that the protocol must allow the
middlebox to notify the agent of significant events, such as ...
Right now it's a little too much like an enumeration of events.

Melinda

_______________________________________________
midcom mailing list
[email-masked]
http://www1.ietf.org/mailman/listinfo/midcom

---

From: "Sanjoy Sen" <[email-masked]>
Date: Mon, 24 Sep 2001 14:39:35 -0500

> From: Scott Brim [mailto:[email-masked]]
> Sent: Monday, September 24, 2001 1:10 PM
> To: midcom
> On Mon, Sep 24, 2001 12:56:40PM -0500, Sanjoy Sen allegedly wrote:
> > > You want to know when a ruleset timer expires?  But 
> you're the one who
> > > set it.  
> > 
> > The Midcom Agent may not want to maintain the timer state. 
> It may just want
> > to install a timer state in the MB and be notified when the 
> timer expires &
> > react to that notification with specific activities.
> 
> This is a months-old argument, about where to put the complexity.
> Recent trends seem to be to pile complexity in the agent and keep the
> middlebox simple -- viz. the example of a simple bump-in-the-wire
> firewall, and the tendency to bundle application proxies with midcom
> agents.  That's evidence of where people seem to want to go.  I also
> think it's a safer base for the future to keep control state 
> complexity
> in the controller, not the controlled object.  That's about 
> fate-sharing
> and "ownership" of state.
> 

If I remember correctly, people actually thought that there was no need for
the Agent to maintain the timer state as they'll be maintained by the MB
anyway (what's the purpose of reqmts R6 & R81? What if the Agent dies after
installing a ruleset?). If the MA is not keeping timer state, how would it
know when to refresh the ruleset unless notified by the MB?

---

From: "Tom-PT Taylor" <[email-masked]>
Date: Tue, 25 Sep 2001 09:43:48 -0400

This seems to be suggesting a requirement for an "end of flow" event
notification.

-----Original Message-----
From: Mark Duffy [mailto:[email-masked]]
Sent: Monday, September 24, 2001 3:59 PM
To: Scott Brim; midcom
Subject: Re: [midcom] Latest requirements bullets resolved

At 02:10 PM 9/24/01 -0400, Scott Brim wrote:
>> > You want to know when a ruleset timer expires?  But you're the one who
>> > set it.  
>> 
>> The Midcom Agent may not want to maintain the timer state. It may just
want
>> to install a timer state in the MB and be notified when the timer expires
&
>think it's a safer base for the future to keep control state complexity
>in the controller, not the controlled object.  That's about fate-sharing

I believe that midcom should permit/support transport-layer aware
middleboxes.
This involves, for example, the ability for an agent to tell a mb to
install a ruleset for a particular tcp n-tuple that must originate in a
certain direction  and that is to permit packet flow in both directions
from the time the tcp connection is established until it is brought down,
and no more packets thereafter.

This is not a philosophical choice about where to put the complexity.  If a
scenario involves a media flow that does not pass through the agent, the
agent cannot inspect the transport connection state.  Even if the flow
passes through the agent, it is likely that the agent hardware is not
optimized for this type of inspection.  On the other hand, this is exactly
the sort of behaviour that firewalls and NATs are designed for and exhibit
*today*.

i think we have agreed that port numbers are part of the filter spec.  That
to me implies that the middlebox may be "transport layer aware".  I view
that awareness as not limited to static awareness of the transport layer
but also allowing for stateful awareness.

-Mark