Subject: RE: [midcom] policy & duration

From: "Reinaldo Penno" <[email-masked]>
Date: Wed, 8 Aug 2001 16:27:59 -0700

Hello,

I also think that besides direction, interface should be included. 

Actually I think this 5 tuple should be a N tuple. We might say that some of
the parameters must be understood (like the basic 5 tuple), and others are
optional. 

Since we are taking intelligence out of the box, I need the agent to be able
to tell me how to apply firewall/NAT for overlapping ip address for
different customers, which might even be dynamic, asymetrical routing, etc.
Allowing someone to put more information on the <tuple> would make it
feasible/easier.

Forget me if I got the wrong impression, but browsing through the emails on
the list if seems that we want to take the intelligence out of the
middlebox...but not quite. It seems we are taking out intelligence of a
middlebox that's not that intelligent, since we are not asking much from the
capabilities of the agent.

regards,

Reinaldo 

> -----Original Message-----
> From: Mark Duffy [mailto:[email-masked]]
> Sent: Wednesday, August 08, 2001 7:22 AM
> To: [email-masked]; Scott Brim
> Cc: [email-masked]
> Subject: Re: [midcom] policy & duration
> 
> 
> At 05:35 AM 8/8/01 -0700, Eliot Lear wrote:
> >Scott Brim wrote:
> ...
> >> There's a hint of directionality in here, which we're 
> still debating.
> >
> >First, very basic packet firewalls understand packets and 
> not connections
> >or conversations.  I don't know that we want to require much 
> more than
> >that.
> >
> >Also, I think we remove directionality at our peril.  In an
> >internal/external communication, the reversing of 
> directional rules on
> >interfaces would lead to a weakening of enterprise security.
> 
> Not only that, but the directionality is already an aspect of 
> the existing
> firewall functionality we are providing control over.  I too believe
> directionality should be included.
> 
> 
> 
> _______________________________________________
> midcom mailing list
> [email-masked]
> http://www1.ietf.org/mailman/listinfo/midcom
>

---

From: Andrew Molitor <[email-masked]>
Date: Wed, 8 Aug 2001 18:36:08 -0500 (CDT)

> capabilities of the agent.

	We say this, I think. I think we MEAN that we want to remove
application specific code from the middlebox. I am all for lots of
intelligence in middleboxes, just nothing specific to SIP or whatever.

---

From: Eliot Lear <[email-masked]>
Date: Thu, 09 Aug 2001 02:20:33 -0700

> intelligence in middleboxes, just nothing specific to SIP or whatever.

A firewall will have what functionality its vendors and users want it to
have. Maybe that will include SIP. Maybe not.  Maybe it will include SMTP
or FTP.  Maybe not.  This is not an either/or proposition.
--
Eliot Lear
[email-masked]

---

From: "Mark Pietras" <[email-masked]>
Date: Thu, 9 Aug 2001 04:44:41 -0500

> or FTP.  Maybe not.  This is not an either/or proposition.

The point is that the functions are LOGICALLY separated in this architecture.  If a middlebox and a MA are implemented on the same PHYSICAL box, so be it.  I suppose it's also possible to have a MA in the same physical middlebox for some functions, and a MA on a different physical box for other functions.

Mark Pietras
[email-masked]