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

From: "Reinaldo Penno" <[email-masked]>
Date: Fri, 10 Aug 2001 01:40:37 -0700

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.

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 

> -----Original Message-----
> From: Jiri Kuthan [mailto:[email-masked]]
> Sent: Thursday, August 09, 2001 3:53 PM
> To: Penno, Reinaldo [SC9:T327:EXCH]; 'Andrew Molitor'; 
> [email-masked]'
> Subject: RE: Expressiveness of Filtering Expression (was RE: [midcom]
> poli cy & duration
> 
> 
> At 06:35 PM 8/9/2001, Reinaldo Penno wrote:
> >Filter based on TCP flags 
> 
> I buy this one. I am also eager to buy DS fields. (I'm not his word)
> kidding, I myself
> did propose this in Section 4.5.1 of draft-kuthan-fcp-02.txt).
> 
> 
> >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 
> 
> 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
> 
>

---

From: Abdallah Rayhan <[email-masked]>
Date: Fri, 10 Aug 2001 11:41:33 -0400 (EDT)

> 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

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

---

From: Scott Brim <[email-masked]>
Date: Sun, 12 Aug 2001 07:54:39 -0400

> 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: Melinda Shore <[email-masked]>
Date: Mon, 13 Aug 2001 06:59:28 -0400

>That is bringing the application awareness back into the

Two things: 1) you can filter on elements in the IP packet
header other than addresses and ports, and 2) you can filter
on values at fixed offsets (although you might get into trouble
if options are present).

Melinda