Subject: [midcom] Terminology discussion - regroup

From: Mark Duffy <[email-masked]>
Date: Mon, 10 Sep 2001 18:24:39 -0400

OK, lots of emails today on this.
Here is an updated proposal in which I have attempted to incorporate the
results of the discussion.  (Noting that there have been assorted opinions
expressed and this certainly doesn't satisfy everything that everyone asked
for.)  I got rid of the word "action".

Classifier Rule
    Packet matching information that identifies a set of packets to be
treated a certain way by a middlebox.     [[Note: I tried "Matching Rule"
here but felt it would create ambiguities in some contexts where it could
be confused with "a rule that does match".]]
 
Disposition Rule
    Description of the middlebox treatment/service to be applied to a set
of packets.  

Ruleset
    The combination of one or more classifier rules and one or more
disposition rules.  Packets matching the classifier rule(s) are to be
treated as specified
by the associated disposition rules(s).  The ruleset may also contain
auxiliary attributes such as ruleset type, timeout values, creating agent,
etc.  

Pinhole -- eliminate this term if possible.  Else:
    A behavior of a firewall-type middlebox to allow a specified set of
packets to traverse the middlebox.  Pinholes instigated via the midcom
protocol are described by Rulesets.

Pinhole-descriptor  -- replace uses of this term with "ruleset".

Flow  --
Resource -- 
   Do not define these in the terminology section.  Use them as general
english words as needed in the text.

Connection -- eliminate use of this word to refer to the association
between midcom agent and middlebox.  Instead use the term Midcom Session as
recently proposed.

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

---

From: Melinda Shore <[email-masked]>
Date: Tue, 11 Sep 2001 09:16:46 -0400

Let's focus on getting this resolved in the next few days.
Are there objections to anything in this proposal?

Melinda

---

From: Pyda Srisuresh <[email-masked]>
Date: Tue, 11 Sep 2001 07:10:53 -0700 (PDT)

> for.)  I got rid of the word "action".
Thanks, Mark, for summarizing.

> be confused with "a rule that does match".]]

I suspect, you are trying to name the packets that are subject to 
middlebox scrutiny (e.g., those that are dropped by firewall, those
that are translated by NAT). Firewall finds these using a matching 
classifier rule-set. NAT finds these by matching the src/dest address
(and port) against the configured address maps.

I am not certain there is a good term for describing this. If we have
to name one, I would prefer if this were renamed, "Middlebox classifier
rule".

>     Description of the middlebox treatment/service to be applied to a set

I would prefer if this were renamed "Middlebox-Disposition".
Disposition is not a rule. Disposition is a process or a function or 
an action.

Middlebox disposition is a middlebox-function specific treatment on 
the packet.

> auxiliary attributes such as ruleset type, timeout values, creating agent,

Now, this gets a bit murky.

Here we are trying to describe parameters that guide the middlebox 
function. Why dont we call them simply as "Middlebox configuration 
parameters"? The config will include middlebox function specific
parameters - such as firewall ACLs, NAT address maps, timeouts etc.
This cannot simply be a set of rule oriented tuples such as 
(Middlebox-classifier-rule, Middlebox-disposition-funtion). The tuples
are just one of the config parameters.
 
> protocol are described by Rulesets.

This is a firewall specific middlebox-classifier rule.

> Pinhole-descriptor  -- replace uses of this term with "ruleset".

Suggest droping the term.
A firewall may be described by a list of pinholes and the associated
dispositions.

> english words as needed in the text.
Agreed.
 
> between midcom agent and middlebox.  Instead use the term Midcom Session as

OK

regards,
suresh

=====

__________________________________________________
Do You Yahoo!?
Get email alerts & NEW webcam video instant messaging with Yahoo! Messenger
http://im.yahoo.com

---

From: Mark Duffy <[email-masked]>
Date: Tue, 11 Sep 2001 18:25:02 -0400

Hi Suresh,  see comments added below...   -Mark

>to name one, I would prefer if this were renamed, "Middlebox classifier

A little longer and hence less convenient than just "classifier rule"  but
if folks prefer this I don't object.

>Middlebox disposition is a middlebox-function specific treatment on 

"Middlebox disposition" suggests to me that it refers to what happened to a
particular middlebox.  E.g.:
  Jim    "What was the disposition of that middlebox?"
  Mary:  "I unplugged it and put it in the rubbish"
"Packet Disposition" would be a bit better.  My personal preference is
still for "Disposition Rule" but if folks prefer this I don't object.

>are just one of the config parameters.

I actively disgree with you on that.  In my mind middlebox configuration
parameters are information put in the middlebox typically by a human
operator.  Things like its interfaces, its IP addresses, how to do logging,
policy, etc. etc.

The Rulesets are somewhat more dynamic and from midcom perstective will be
put in the middlbox by a midcom agent.

I would daresay that many middleboxes may support access to similar
functionality via configuaration as via midcom.  I.e. a firewall might
allow traversal of a set of packets because it was so directed by its
configuration, or because it was so directed by a midcom agent.  But I
don't believe that what the midcom agent sends to the middlebox should be
called "configuration".

>This is a firewall specific middlebox-classifier rule.

In my mind "pinhole" is not a "middlebox-classifier rule" aka "classifier
rule".  Rather, it is a thing/behavior manifested by a firewall middlebox
as a result of being told to install a ruleset.  Of course, if we can just
eliminate this term that would be easiest all around!

---

From: Pyda Srisuresh <[email-masked]>
Date: Wed, 12 Sep 2001 11:04:15 -0700 (PDT)

> Hi Suresh,  see comments added below...   -Mark
<... stuff deleted> 
> still for "Disposition Rule" but if folks prefer this I don't object.

Hmm.. The usage above doesnt fit the definition. Middlebox disposition
is a middlebox-function specific treament on a packet (not the box).

If you prefer, we can go with "Middlebox packet disposition" .
But, I am Ok with simple "Middlebox disposition".

> operator.  Things like its interfaces, its IP addresses, how to do logging,

Also included are the middlebox function specific parameters - I.e., the 
firewall ACLs, NAT address maps, timers etc. The agent will likely query 
the middlebox for these parameters.

> put in the middlbox by a midcom agent.

The ruleset may be dynamically changing in the sense that newer resource
allocation/deallocations are signalled by the agent. But, the agent is not
the sole owner of these parameters.

Midcom is an extension to the basic middlebox operation. Not a fork-lift
in the way it is configured and operates.

> don't believe that what the midcom agent sends to the middlebox should be
                     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> called "configuration".

In that case, you are merely refering to the Midcom-agent signalled
resources/parameters - not the whole ruleset and other middlebox
parameters. Midcom agent may have no control over some of the basic 
rules, such as NAT address maps, and default TCP/UDP session timers.
Midcom agent may be allowed to make individual session specific 
paramter changes, not the middlebox function configuration as a whole.

> eliminate this term that would be easiest all around!

Hmm.. sounds very confusing. Is it permit on a pinhole (or) deny
on a pinhole you are refering to as the bahaviour manifested. I have
no issues with dropping the term.

<... stuff deleted>

regards,
suresh

---

From: Melinda Shore <[email-masked]>
Date: Fri, 14 Sep 2001 10:19:29 -0400

It doesn't yet appear that we have agreement on the proposed
terminology.  Where do we stand with it?

Melinda

---

From: Scott Brim <[email-masked]>
Date: Fri, 14 Sep 2001 10:51:44 -0400

> terminology.  Where do we stand with it?

I have no objections to anything proposed.

---

From: Mark Duffy <[email-masked]>
Date: Fri, 14 Sep 2001 11:01:17 -0400

>terminology.  Where do we stand with it?

After a great deal of discussion on the list I posted an updated proposal
on Sep 10 which Melinda sent out again on Tue, 11 Sep 2001 09:16:46 -0400
with a call for comments.

My personal assesment is that:
-I myself agree with the proposal :-) but tire of the issue
-Scott Brim is satisfied with it
-I believe John LaCour and Bob Penfield are satisfied with it as they
commented on certain aspects.
-I suspect Christian is not entirely happy with it but I don't know of
specific changes he would like made.  
-Suresh has some significant disagreements.  He would like to see different
terms used in several cases and I believe he disagrees somehat with what
the concept of Ruleset encompasses (vs middlebox "configuration").
-I don't recall any other input.

If I've misrepresented anyone, I'm sure they'll speak up and my most
sincere apologies.

---

From: "Bob Penfield" <[email-masked]>
Date: Fri, 14 Sep 2001 12:16:56 -0400

When I last commented on these, we had Filter Spec and Action Spec, which I
prefer to the currently proposed terms. However, like Mark, I tire of the
issue. Frankly, I don't see why we cannot use simple one or two word terms
that have a specific meaning in a midcom document just like other documents.
For example, SIP uses the terms like session and server. Megaco uses
context, termination, media, and stream. If you need to use them in another
context, you just insert MIDCOM in front of them. I think we got into
trouble when we started looking for terms that would be totally unambiguous
in all space and time.

That's my rant. I will be quite now (on this subject anyway), and will not
object if the current proposal is adopted.

(-:bob

Robert F. Penfield
Chief Software Architect
Acme Packet, Inc.
130 New Boston Street
Woburn, MA 01801
[email-masked]

---

From: Pyda Srisuresh <[email-masked]>
Date: Sun, 16 Sep 2001 10:01:15 -0700 (PDT)

It has been tiring, no doubt. Below, is a summary , as I understand, 
of terms that came up for discussion.

     - keep "Middlebox classifier rule"
     - Keep "Middlebox packet disposition"
     - Replace "Connection" with "Middlebox session"
     - Drop "flow", "resource"
     - Drop "Pinhole"
     - Drop "Pinhole descriptor"
     - Drop "Filter Spec", "Action Spec" in preference to
       "Middlebox classifier rule" and "Middlebox packet disposition"?
     - Debate over "Ruleset" vs "Configuration" - Semantics difference.

Are we OK on the first seven items?  MUST the debate on 8th be pursued?

Melinda or Scott - Could one of you please summarize what in your mind 
needs done to move the framework draft through a second WG last call
successfully. Thanks.  

cheers,
suresh

=====

__________________________________________________
Terrorist Attacks on U.S. - How can you help?
Donate cash, emergency relief information
http://dailynews.yahoo.com/fc/US/Emergency_Information/

---

From: Melinda Shore <[email-masked]>
Date: Mon, 17 Sep 2001 09:01:00 -0400

>needs done to move the framework draft through a second WG last call

The first thing that ABSOLUTELY must be done is to get the
terminology issues resolved and the documents aligned.  The
other problem is going to be the topology issue, which is
going to require feedback from the ADs (I'm pursuing that).
Other than that, any agreed-upon changes to the requirements
need to be reflected back into the framework document.

Melinda

---

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

At 09:01 AM 9/17/01 -0400, Melinda Shore wrote:
...
>terminology issues resolved and the documents aligned.  The
...
>Melinda

Let me try again on the terminology.  As far as I can see there seems to be
agreement on the definitions and on what terms to define, not define,
eliminate, etc.  I reiterate below.  I think there is not yet agreement on
the _names_ for a few terms, indicated below with ***.  I suggest that we
vote, roll a die, or better yet ask some disinterested party which choice
they think best fits the definition and then just accept their choice.

Name: *** NOT YET AGREED, HAVE THE FOLLOWING PROPOSALS:
   Filter Spec
   Classifier Rule
   Middlebox Classifier Rule
Definition: 
   Packet matching information that identifies a set of packets to be
   treated a certain way by a middlebox.

Name: *** NOT YET AGREED, HAVE THE FOLLOWING PROPOSALS:
   Action Spec
   Disposition Rule
   Middlebox Disposition
   Middlebox Disposition Rule
   Middlebox Packet Disposition
Definition:
   Description of the middlebox treatment/service to be applied to a set
   of packets.  

Name: *** NOT YET AGREED, HAVE THE FOLLOWING PROPOSALS:
   Ruleset
   Middlebox Configuration Parameters
Definition:
   The combination of one or more <<classifier rules>> and one or more
   <<disposition rules>>.  Packets matching the <<classifier rule(s)>>
   are to be treated as specified by the associated <<disposition 
   rules(s)>>.  The <<ruleset>> may also contain auxiliary attributes
   such as <<ruleset>> type, timeout values, creating agent, etc.

Name: Midcom Session
Definition:
   A lasting association between a MIDCOM agent and a middlebox. The 
   MIDCOM session is not assumed to imply any specific transport layer
   protocol.  Specifically, this should not be construed as referring
   to a connection-oriented TCP protocol.

Pinhole -- 
   eliminate use of this term in the documents.

Pinhole-descriptor  -- 
   eliminate use of this term in the documents. (Many instances can
   probably be replaced with the term <<ruleset>>).

Flow  --
Resource -- 
   Do not define these in the terminology section.  Use them in their
   general english language sense as needed in the text.

Connection -- 
   eliminate use of this word to refer to the association between 
   midcom agent and middlebox.  Instead use the term "Midcom Session"

P.S. Is it "midcom", "Midcom", "MIDCOM" or something else?  It would be
nice to  be consistent.

---

From: Scott Brim <[email-masked]>
Date: Mon, 17 Sep 2001 20:40:48 -0400

> Name: *** NOT YET AGREED, HAVE THE FOLLOWING PROPOSALS:

These are close enough that it doesn't matter.

>    Middlebox Classifier Rule

"Middlebox" is unnecessary and potentially confusing.

OK

>    Middlebox Packet Disposition

No, same reasons :).  I'm against adding "Middlebox" in general because
*obviously* we're using these in the context of middleboxes -- look at
the definition below, for goodness' sake -- and calling them "middlebox"
things makes people wonder what other things {action specs, etc.) there
might be.  Are we going to have middlebox frame dispositions or
something?  Leave it clean and simple, the way we had it a week ago.

>    Middlebox Configuration Parameters

If this is the only alternative to Ruleset then I'm definitely for
Ruleset.  Middlebox configuration parameters can be anything, for
example what IP address prefixes are to be found out interface 3.  Also
rulesets are not necessarily installed by configuration.

>    such as <<ruleset>> type, timeout values, creating agent, etc.

OK.  If someone feels a need to distinguish between what is carried in
the protocol and what is installed in the middlebox, the former is
in-scope and the latter is not, so we are only creating a definition for
what goes into the protocol.

OK

OK

> P.S. Is it "midcom", "Midcom", "MIDCOM" or something else?  It would be

Aha :-).  I use Midcom Working Group but the midcom protocol.  "midcom"
is an abbreviation but it's not made up of the first letters of its full
name, so I don't like to capitalize it completely, like BGP or SIP or
HIP.  If you're not going to capitalize it completely then the only
alternative is not to capitalize it at all.  I'm trying to think of
another protocol whose name is constructed like this.  Y'know what, it
doesn't matter much, because the next WG is going to specify it as an
extension of an existing protocol anyway.

..Scott

---

From: Pyda Srisuresh <[email-masked]>
Date: Tue, 18 Sep 2001 05:54:00 -0700 (PDT)

OK. That is in line with my thinking. Thanks.

regards,
suresh

=====

---

From: Melinda Shore <[email-masked]>
Date: Tue, 18 Sep 2001 08:56:02 -0400

Okay, let's get these closed so we can move on.  Many thanks to 
Mark and those who've been whacking away at this.  It's not fun work
but it's important and necessary.

Name: Filter Spec (short for filter specification - "Spec" isn't a
   word)
Definition: 
   Packet matching information that identifies a set of packets to be
   treated a certain way by a middlebox.

Name: Action Spec (ditto on the "spec" thing)
Definition:
   Description of the middlebox treatment/service to be applied to a set
   of packets.  

Name: Ruleset
Definition:

Name: Midcom Session
Definition:

Melinda

---

From: Scott Brim <[email-masked]>
Date: Tue, 18 Sep 2001 10:14:30 -0400

>    Description of the middlebox treatment/service to be applied to a set

Nicely done.

>    such as <<ruleset>> type, timeout values, creating agent, etc.

You can fill in the placeholders based on what's above.

I won't quibble over rulesets "containing" attributes. :)

---

From: Pyda Srisuresh <[email-masked]>
Date: Tue, 18 Sep 2001 18:00:35 -0700 (PDT)

>    treated a certain way by a middlebox.

I can go with this.
However, if I were to pick between this and <<classification rule>>,
I would go with the latter.

>    Description of the middlebox treatment/service to be applied to a set

I can go with this. But, just pick one between this and <<disposition rule>>.
not both. I am Ok with either.
 
>    such as <<ruleset>> type, timeout values, creating agent, etc.

This looks better. Couple of questions below.

If classification is per-packet based, how do you specify session based
classification? Is it fair to assume that <Packet based classification vs
session based classification> and <packet direction vs. session direction>
will be classification criteria?

If I(MIDCOM agent) were to request an Address-Binding or Port-Binding, 
how would that fit into the ruleset above? Is that even supposed to
fit into the ruleset, considering there is no single packet or session
involved?

If I(MIDCOM agent) were to request for a NAT session creation with
certain Address/Port-Binding, how would I do that using the <<ruleset>>
above?

regards,
suresh

---

From: Scott Brim <[email-masked]>
Date: Wed, 19 Sep 2001 09:43:35 -0400

> will be classification criteria?

Suresh has a point.  Will it be possible to specify stateful 
rules in the midcom protocol, or can rules only be based on individual
packet attributes?  Will stateful inspection be limited to agents?  I
don't think we brought this out in the requirements.

> certain Address/Port-Binding, how would I do that using the <<ruleset>>

The filter spec would match one side of the binding and the action spec
the other side.  Functionally what does an address binding actually do?
In this case, minimally, you filter for "packets destined for address
foo", and the action would be "translate that to address bar".

..Scott

---

From: Mark Duffy <[email-masked]>
Date: Wed, 19 Sep 2001 11:02:01 -0400

>don't think we brought this out in the requirements.

We had some discussion earlier on about the fact that midcom facilitates
removing application intelligence from the middleboxes, but at what level
does "application" begin.  I believe we concluded that middleboxes are
generally expected to remain aware of transport layer protocols e.g. tcp.
(See
http://www1.ietf.org/mail-archive/working-groups/midcom/current/msg00663.htm
l and other messages in that thread.)

Therefore, I have been believing that the Action Spec will include such
possible actions as 
 - allow individual packets to pass in a certain direction  (stateless)
 - allow tcp connection in both directions as long as initial syn flows in
a certain direction (tcp-stateful)

R44 covers the direction aspect.

See
http://www1.ietf.org/mail-archive/working-groups/midcom/current/msg00977.htm
l for a proposed requirement about the stateful behavior.

-Mark

---

From: Pyda Srisuresh <[email-masked]>
Date: Thu, 20 Sep 2001 07:17:19 -0700 (PDT)

> don't think we brought this out in the requirements.
As I understand, the intent of the ruleset definition is to be able to
describe rules that may be communicated over the MIDCOM protocol. As such,
defining ruleset as per-packet based is inadequate for the purpose.

As for "Will stateful inspection be limited to agents?", I am not sure
I understand the question. Application specific stateful processing will
be with the agent. However, that would still leave application-independent
per-session state management to the middlebox.

> the other side.  Functionally what does an address binding actually do?

Address-binding, as a whole, is what you might call the action spec that 
dictates action for one or more sessions that use the Address-Binding. 

When a packet is classified as belonging to one of the NAT-managed
sessions, the associated Address-binding (or Port-Binding) is applied.

> foo", and the action would be "translate that to address bar".

Scott - the above description is packet centric. Whereas, NAT paradigm
is session based.

Just because you have an address binding defined on a NAT middlebox, 
it does not mean that any packet traversing the box can use the binding.
Only sessions initiated in a certain direction, or sessions permitted
by the agent to use the address binding are allowed to use the binding.
If a packet does not belong to any of NAT managed sessions, either the
packet is dropped or a new session-state is created (if the packet meets
the criteria required of a first packet)

regards,
suresh

---

From: Pyda Srisuresh <[email-masked]>
Date: Thu, 20 Sep 2001 07:40:45 -0700 (PDT)

> l and other messages in that thread.)

I recall the discussion. But, I dont believe that touches upon specifying
session-based rules.

> a certain direction (tcp-stateful)

The first  spec above is inherently packet based.
The second spec - A TCP trick of being able to permit/deny a TCP session
based on the SYN flag of the first packet alone and permitting all TCP 
packets otherwise - You were able to synthesize a TCP-session based 
firewall rule into a per-packet firewall rule. Fine.

Both these ilustrations are firewall/packet centric and will not 
suffice for NAT.

regards,
suresh

=====

---

From: Mark Duffy <[email-masked]>
Date: Thu, 20 Sep 2001 12:35:44 -0400

>firewall rule into a per-packet firewall rule. Fine.

I wouldn't call that a "trick".  
Perhaps you are reacting to my wording, which was quite specific in an
attempt to convey the point succinctly by example.  Let me try wording the
stateful type action more generally:

   - allow packets to pass in both directions within a transport layer
(e.g. tcp) connection/sesssion/whatever as long as the
connection/sesssion/whatever is initiated in a certain direction. (firewall
stateful action spec)

>Both these ilustrations are firewall/packet centric and will not 

I would see NAPT being much the same: apply a translation on a
per-transport-layer session basis.   Just as with stateful firewall rule,
the middlebox must be aware of the transport layer sessions.  However, for
NAT without port translation, the middlebox doesn't need to be aware of the
trasnport sessions.

---

From: Scott Brim <[email-masked]>
Date: Thu, 20 Sep 2001 13:04:36 -0400

> the criteria required of a first packet)

I think the confusion is over the use of 'session', and it comes down to
this paragraph.  A "binding" cannot be used unless the use is initiated
from a particular direction.  What other criteria are which a NAT can
use to decide if a particular packet which would use a particular
address binding belongs to a "session" which is allowed?

---

From: Pyda Srisuresh <[email-masked]>
Date: Fri, 21 Sep 2001 11:36:54 -0700 (PDT)

--- Scott Brim <[email-masked]> wrote:
> this paragraph.
Yes.
 
>                 A "binding" cannot be used unless the use is initiated
> from a particular direction. 

Right. A binding cannot be used unless a session (in a particular 
direction w.r.t. to NAT enabled interface) is created to use the binding.

>                              What other criteria are which a NAT can
Well, depending upon the NAT type (Basic-NAT, NAPT, bi-directional NAT
or Twice-NAT), the NAT device inherently has guidelines to create/permit
sessions in a specific direction. 

Basic-NAT and NAPT, which are the most popular type of NAT types 
permit outbound sessions only.

Hope this helps. Thanks.

Regards,
suresh