Subject: RE: [midcom] Terminology discussion - status

From: John LaCour <[email-masked]>
Date: Mon, 10 Sep 2001 10:31:00 -0700

> From: Melinda Shore [mailto:[email-masked]]
> Sent: Monday, September 10, 2001 8:12 AM
> To: [email-masked]
> Subject: [midcom] Terminology discussion - status
> 
> 
> Ruleset:  Scott proposed a definition which hasn't yet received any
> discussion: "A set of rules which are installed and removed 
> as a unit.  
> A combination of a filtering (matching) specification and one or more 
> action specifications.  How complex these can be is not defined."  
> Objections?  Alternatives?

By action we mean "deny", "permit", "nat", "natpt" right?  If so,
I'm ok with this definition.

> Pinhole: There seems to be some sentiment that if the term is to be
> used at all, it's as an instantiation of a rule or ruleset.  It is
> not an abstraction.

Agreed.

> Pinhole-descriptor: Likewise - it's just a ruleset.

I don't like this, it might be confused to be some sort of identifier for
a MIDCOM request for a Ruleset.

> Connection: Them that's spoken have indicated a preference for "midcom
> session."

Agreed with this preference.

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

---

From: Mark Duffy <[email-masked]>
Date: Mon, 10 Sep 2001 14:22:57 -0400

At 10:43 AM 9/10/01 -0700, Christian Huitema wrote:
>We are missing something like a "ruleset type" that defines the type of
>rule and action being considered; we may want to just focus on the
>"5-tuple", but having explicit typing will provide the extensibility
>that some required. By the way, ruleset is kind of hideous. I would
>prefer to replace all occurrences of ruleset by pinhole...

I believe a lot of folks on the list find "pinhole" too firewall-specific.

>> Filter Spec
>>     Packet classifier (matching) information that identifies a set of
>> packets to be treated a certain way by a middlebox.
>
>This is fine.
>
>> Action Spec
>>     Description of the middlebox treatment/service to be applied to a
>> set of
>> packets.
>
>I think that "action spec" is too restrictive. You want something like
>"attributes." Consider as a possible attribute the identity of the agent
>who created the ruleset; this is a useful parameter for access control,
>but it definitely does not define an "action."

See the following definition which says the ruleset may have auxiliary info
besides filter specs and action specs, including "owning agent" (shorthand
for "agent who created the ruleset").  Does that address your point?  Is it
important to you that these other types of attributes be part of the
"Action spec" vs just being part of the overall ruleset?  

I fear this is all getting a bit too detailed and specific, given that the
objective here is to define terms for use in requirements/framework and not
to define the protocol.

>
>> Ruleset
>>     The combination of one or more filter specs and one or more action
>> specs.  Packets matching the filter spec(s) are to be treated as
>> specified
>> by the  associated action spec(s).  The ruleset may also contain
>> auxilliary
>> information such as timeout values, owning agent, etc.
>
>Should add the "ruleset type" to the list.

OK.

>-- Christian Huitema

---

From: "Christian Huitema" <[email-masked]>
Date: Mon, 10 Sep 2001 13:03:54 -0700

> > Frankly, I don't know what the action spec is. I have a hard time
> > instantiating it, and I suspect it is useless in the main
> application,
> > firewall and nat traversal.
> 
> Examples:  "Let the packet through" (that's your standard firewall
> pinhole).  "Translate the source address/port to 192.69.1.201/42".
> "Encapsulate in XML and divert to that OPES service over there" (oops,
> did I say that?).  This is not unusual stuff.  Think in terms of sed.

Actually, I would rather think in term of discrete attributes than text
editor's commands.

"Let the packet through" can just as well be represented by a "status"
attribute with values such as closed, sendonly, recvonly, open.

"Translate" can only be an attribute if the firewall is implementing a
NAT function, and in that case it is pretty much equivalent to "let the
packet through" -- there is no other way. Then, you get attributes, such
as the address mapping or the port mapping; these attributes are
typically present in the commands' responses, "you will be mapped to
192.69.1.201:42", and are typically optional in the request "I would
like port 80."

-- Christian Huitema

---

From: "Christian Huitema" <[email-masked]>
Date: Mon, 10 Sep 2001 12:56:48 -0700

> An action spec is a "command" (install, delete, modify, etc.).
> I still don't like this approach, but there has been some feeling
> for having commands as parameters rather than as, uh, commands.

Then, I like it even less. The command is there to affect the set of
"rulesets" that are present in the firewall; the command itself cannot
an attribute of the ruleset.

-- Christian Huitema