Subject: RE: [midcom] Latest requirements bullets resolved

From: "Sanjoy Sen" <[email-masked]>
Date: Mon, 24 Sep 2001 12:56:40 -0500

> -----Original Message-----
> From: Scott Brim [mailto:[email-masked]]
> Sent: Monday, September 24, 2001 11:30 AM
> To: midcom
> Subject: Re: [midcom] Latest requirements bullets resolved
> 
> 
> 
> 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.

---

From: Scott Brim <[email-masked]>
Date: Mon, 24 Sep 2001 14:10:24 -0400

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

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

---

From: Mark Duffy <[email-masked]>
Date: Mon, 24 Sep 2001 15:59:03 -0400

>and "ownership" of state.

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