Subject: [midcom] precedence of rules?

From: Mark Duffy <[email-masked]>
Date: Fri, 17 Aug 2001 11:02:15 -0400

I hope I'm not adding fuel to a fire we are trying to extinguish but...  I
don't recall any discussion about precedence of rules installed into the
middlebox.

Assuming that rules may be specified whose packet-matching criteria contain
masks/wildcards/don't-cares in any of their fields, then it becomes
possible for more than one (possibly conflicting) rule to match any given
packet.  Moreover, there is no meaningful way to impose a canonical
ordering on such rules.  IMHO, having the middlebox order the rules however
it pleases is unacceptable.

To me this suggests that the agent must be able to specify a precedence for
each rule it installs.  But this gets sticky when there are multiple agents
directing the same mb.  

Any thoughts?

--Mark

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

---

From: Scott Brim <[email-masked]>
Date: Fri, 17 Aug 2001 11:08:14 -0400

> each rule it installs.  But this gets sticky when there are multiple agents

Yes, but let's not go there this week :-).  Adding precedence to the
syntax will be an easy add-on if and when we or the next WG decide to do
it.

---

From: Melinda Shore <[email-masked]>
Date: Fri, 17 Aug 2001 11:12:19 -0400

>Any thoughts?

I'd really like to keep us moving forward, and one thing that 
would help is if when you want to see something added, you 
propose actual text.  I continue to be somewhat concerned that
we're designing a camel, either way.

Melinda

---

From: "Ram Dantu" <[email-masked]>
Date: Fri, 17 Aug 2001 10:24:12 -0500

I think Melinda's wording does cover extensibility
but to be more explicit, I would suggest the following

The midcom protocol must be able to carry filtering rules,
like 5-tuple and to be extensible, from the midcom
agent to the middlebox.  

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of
Melinda Shore
Sent: Friday, August 17, 2001 10:12 AM
To: Mark Duffy; [email-masked]
Subject: Re: [midcom] precedence of rules?

Melinda

---

From: Keith Moore <[email-masked]>
Date: Mon, 20 Aug 2001 10:25:44 -0400

I realize this will be unpopular, but I actually believe that the
midcom filtering rules should not be extensible.  The reason is
that I see midcom as a stopgap measure.  Topological filtering is
not something that should be encouraged as part of the architecture,
and the notion that midcom can or should someday be extended to solve 
this problem is IMHO fanciful.

Keith

---

From: "Ram Dantu" <[email-masked]>
Date: Mon, 20 Aug 2001 09:54:44 -0500

I do not understand what you mean by midcom is a stopgap measure.
Can you please explain why you think filtering rules should
NOT be extensible ?  

Midcom wg is discussing whether topology information is required 
as part of the communication between agent and middlebox. This
particular info. may be optional.

Ram Dantu

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of
Keith Moore
Sent: Monday, August 20, 2001 9:26 AM
To: Ram Dantu
Cc: 'Melinda Shore'; 'Mark Duffy'; [email-masked]
Subject: Re: [midcom] precedence of rules? 

Keith

---

From: Melinda Shore <[email-masked]>
Date: Mon, 20 Aug 2001 11:06:06 -0400

>Can you please explain why you think filtering rules should 

Hi -

I think that in general the question of the stopgapness of midcom 
probably belongs on the general ietf mailing list or in off-mailing-
list discussions with the IESG or IAB.  Let's try to limit discussion
of that issue to how it might affect protocol requirements (yes, that's
*way* too vague, but what I'm saying is that while the issue has some
relevance to the deliverables we cannot get sucked into another 
Good vs. Evil argument).

Melinda

---

From: Keith Moore <[email-masked]>
Date: Mon, 20 Aug 2001 12:44:10 -0400

> Can you please explain why you think filtering rules should

Because firewalls in general are a stopgap measure.  Security boundaries 
do not naturally follow network topology, particularly in a world where 
wireless access is common.  It doesn't scale to expect the network 
(and I include middleboxes in the network) to be aware of applications, 
nor to expect applications to be aware of network topology.

I'm not trying to argue good vs. evil, but I do want to argue against the 
assumption that it's reasonable to extend the work currently being done 
by midcom.  And I'm not trying to distract the midcom group from its 
immediate goal as defined by its charter. But since there's a general 
tendency to believe that silence = assent, I think it's necessary for 
dissenting voices to speak up once in awhile.

your loyal dissenter,

Keith

---

From: Abdallah Rayhan <[email-masked]>
Date: Tue, 21 Aug 2001 14:41:33 -0400 (EDT)

The thing about extensibility is that it brings us back into
integrating application intelligence into the middlebox
which is something the WG is trying to avoid. I believe
that the term and the application of extensibility is and
going to be abused badly and will introduce vendor 
incompatibility. 

IMHO, when extensibility is discussed it should be focused
on new types of agents and new types of middleboxes and not
over stretching the protocol to over NAT or over filter 
packets in the firewall.

regards
Abdallah

> we're designing a camel, either way.

_______________________________________________________
Do You Yahoo!?
Get your free @yahoo.ca address at http://mail.yahoo.ca

---

From: Scott Brim <[email-masked]>
Date: Tue, 21 Aug 2001 14:46:13 -0400

> over stretching the protocol to over NAT or over filter 

Sounds good to me.  That's what R41 and R2 were meant for.

btw there should be a new version of the bullets available in a few
minutes.

---

From: Eliot Lear <[email-masked]>
Date: Tue, 21 Aug 2001 11:49:35 -0700

Quite frankly I think the reason extensibility is an issue is that
different people have different goals.  If you're a firewall vendor,
perhaps you want to make your box more intelligent, and that you'd like to
parse more stuff.  If you build policy boxes, you need a way to opaquely
pass some amount of information into the policy system.  This is
particularly the case if the end host *is* the midcom agent.  This,
combined with the experimental nature of the middle box approach, is why
we cannot come to consensus on this point.
--
Eliot Lear
[email-masked]

---

From: "Ram Dantu" <[email-masked]>
Date: Tue, 21 Aug 2001 14:17:27 -0500

Middleboxes can offer several other features than
just one function (e.g., opening a pin hole using the 5-tuple).
Eliot Lear has stated this more explicitly with examples(please see his
email).
In this context, I do not see any reason limiting to 5-tuple.

Several IETF protocol information elements were extended
several times and I do not call it abuse.

Having said that I have no objection for Melinda's proposal
("including but not limited to 5-tuple")

Regards
Ram Dantu

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of
Abdallah Rayhan
Sent: Tuesday, August 21, 2001 1:42 PM
To: [email-masked]
Subject: [midcom] Rule Extensibility

regards
Abdallah