Subject: RE: Expressiveness of Filtering Expression (was RE: [midcom] poli cy & duration

From: "Reinaldo Penno" <[email-masked]>
Date: Thu, 9 Aug 2001 09:35:45 -0700

> -----Original Message-----
> From: Jiri Kuthan [mailto:[email-masked]]
> Sent: Thursday, August 09, 2001 9:29 AM
> To: Penno, Reinaldo [SC9:T327:EXCH]; 'Andrew Molitor'; 
> [email-masked]'
> Subject: Expressiveness of Filtering Expression (was RE: 
> [midcom] policy
> & duration
> 
> 
> At 02:37 AM 8/9/2001, Reinaldo Penno wrote:
> >Hello Andrew,
> > 
> >just adding some points on what we disucssed based on my 
> reading of the charter...
> > 
> >IMO MIDCOM should be a protocol that is general or 
> extensible enough so that I can inform the firewall how to 
> identify, for instance, RTP packets or more generally offsets 
> as you said. 
> > 
> >It seems some people only want to solve specifically "how to 
> pass SIP through a firewall". This is very evident from the 
> fact that some people think 5 tuple is enough. If we are 
> thinking about getting any type of ALGs from the middlebox, 
> put on a MA and still have the same funcionality, clearly 
> this is not enough.
> 
> Could you give me a specific example of an application where 
> a 5-tuple is clearly not 
> enough? 

Filter based on TCP flags
Filter based on type of media carried on RTP
Filter based on HTTP method (GET, POST, etc)
Filter based on URL
Filter based on cookies
Filter based on interface
Filter based on VPN-ID
Filter based on subscribe-ID
Filter based on ranges
Filter based on time of day
Filter based on day of week
Filter based on the temperature outside

My personal opinion is that staying simple is good 
> and if omeone desires
> higher complexity the burden is on him/her to show the need for it.
> 
> -Jiri, the believer in "5-tuple is good enough for removing 
> ALGs from middleboxes"

I would rewrite it as "Jiri, someone that wants to solve his SIP problem"

regards,

-RP

---

From: Jiri Kuthan <[email-masked]>
Date: Fri, 10 Aug 2001 00:52:44 +0200

>Filter based on TCP flags 

I buy this one. I am also eager to buy DS fields. (I'm not kidding, I myself
did propose this in Section 4.5.1 of draft-kuthan-fcp-02.txt).

>Filter based on HTTP method (GET, POST, etc) 

I understand removing application-layer intelligence out of routers is 
midcom WG's goal. From this perspective, filtering on HTTP method, cookies, etc.
does not help me to reach this objective. It could end up with a very
powerful midcom command saying "let SIP sessions go through!". I see
the border line of app-independent midcom protocol between transport 
and application layer. I think application-independence is a feature,
not a bug.

>Filter based on interface 

Filtering based in interfaces/directions is an idea which still deserves to
be discussed. 

>Filter based on ranges 

I'm perfectly fine with ranges of values for whatever field we will have.

BTW, I fear you misunderstood me -- I was not interested in seeinga list of
possible extentensions which is potentially endless. I wanted you to
show what they are needed for.

>I would rewrite it as "Jiri, someone that wants to solve his SIP problem" 

That's absolutely correct :-) I am not interested in solving 
outside temperature problem. Don't get me wrong -- I think
that certain generality is good. But it needs to be well 
justified. Remeber that WG's objective is (at least if I got it
right) to allow for modular FWs/NATs and not necessarily to
build a general-use management protocol.

-Jiri

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

---

From: "Reinaldo Penno" <[email-masked]>
Date: Fri, 10 Aug 2001 09:59:58 -0700

Not true,

I can filter based on offsets and know nothing about the application. This
available today.

regards,

Reinaldo

> From: Abdallah Rayhan [mailto:[email-masked]]
> Sent: Friday, August 10, 2001 8:42 AM
> To: [email-masked]
> Subject: RE: Expressiveness of Filtering Expression (was RE: [midcom]
> poli cy & duration
> 
> 
> --- Reinaldo Penno <[email-masked]> wrote:
> > Jiri,
> > 
> > it seems we are almost in agreement. 
> > 
> > I am not trying to change the MIDCOM protocol upside down. I just
> > want to
> > make the "rule" (I might get killed by using this word) extensible.
> > If, for
> > instance, GMD Fokus wants to write an informational draft proposing
> > an
> > extension of the 5 tuple where the it could signal the middlebox to
> > do
> > filtering based on SIP Messages, INVITEE name, via header, etc, it
> > could. 
> > 
> > I do not know how making the rule extensible could be such a
> > headache. We
> > are not changing the protocol, just the rule object.
> 
> I dont see how that is possible. Once you go beyond L3 upwards
> you are changing a major part of the MIDCOM requirement. 
> That is bringing the application awareness back into the
> middlebox.
> 
> regards
> Abdallah
> 
> _______________________________________________________
> Do You Yahoo!?
> Get your free @yahoo.ca address at http://mail.yahoo.ca
>

---

From: "Reinaldo Penno" <[email-masked]>
Date: Sun, 12 Aug 2001 04:59:00 -0700

yes it is.

thanks,

Reinaldo

> From: Scott Brim [mailto:[email-masked]]
> Sent: Sunday, August 12, 2001 4:55 AM
> To: [email-masked]'
> Subject: Re: Expressiveness of Filtering Expression (was RE: [midcom]
> poli cy & duration
> 
> 
> On Fri, Aug 10, 2001 at 01:40:37AM -0700, Reinaldo Penno 
> apparently wrote:
> > I am not trying to change the MIDCOM protocol upside down. 
> I just want to
> > make the "rule" (I might get killed by using this word) 
> extensible. If, for
> > instance, GMD Fokus wants to write an informational draft 
> proposing an
> > extension of the 5 tuple where the it could signal the 
> middlebox to do
> > filtering based on SIP Messages, INVITEE name, via header, 
> etc, it could. 
> 
>    R2: The syntax and semantics of the Midcom Protocol MUST be
>        extensible to allow the requirements of future applications to
> 	   be adopted.
> 
> Is this requirement enough or not?
>

---

From: Jiri Kuthan <[email-masked]>
Date: Mon, 13 Aug 2001 16:49:10 +0200

I do not think we are in agreement. Again, the value I see in Midcom is it allows for outsourcing 
applications out of routers. If we keep app patchwork in routers, there is little reason for midcom. 
The SIP example I gave before was indeed thought as a demonstration of bad idea.

I think Midcom was chartered to get apps through NATs/firewalls. Keeping things as simple
as possible is good. I welcome good proposals for extensibility model but I am very reluctant
to require too many protocol features unless the need for them is known.

-Jiri

At 10:40 AM 8/10/2001, Reinaldo Penno wrote:

>I am not trying to change the MIDCOM protocol upside down. I just want to make the "rule" (I might get killed by using this word) extensible. If, for instance, GMD Fokus wants to write an informational draft proposing an extension of the 5 tuple where the it could signal the middlebox to do filtering based on SIP Messages, INVITEE name, via header, etc, it could. 
>
>I do not know how making the rule extensible could be such a headache. We are not changing the protocol, just the rule object.
>
>Now, as far as applications that are needed, for instance, URL filtering that I mentioned is an aplication per se. It is used today in several firewalls. The same goes for cookie filtering, etc. These are not extensions, they are applications used by customers/users. I need more than 5 tuple to signal that. 
>
>The same goes for overlapping IP address on the same PE router and SIP example above. 
>
>regards, 
>
>Reinaldo