Subject: [midcom] pin-holes, sessions and flows, oh my!

From: "Bob Penfield" <[email-masked]>
Date: Tue, 7 Aug 2001 08:39:59 -0400

Hi all,

During some informal discussions between several individuals interested in
midcom who happened to be in the bar (although no one had any feathers), it
was noticed that there are variety of inconsistent terms used in the
framework and requirements to describe the thing in the middlebox that we
wish to manage with a midcom protocol.

Our illustrious leader has asked me to take a crack at defining one set of
terms for these things.

There are two things we need to represent: 1) an individual NAT/pin-hole to
enable a stream of packets to traverse the middlebox; and 2) an aggregation
or grouping of NATs/pin-holes that represent a session from the
application's point of view.

Currently, the framework calls an individual thing a session-descriptor, and
the requirements call it a pin-hole. It was felt by a number of those
present that pin-hole implied a firewall function to the exclusion NAT
(Although we realize that is not what was intended). It was also felt by
some people that "session" was overloaded in that it has been used to
describe an individual pin-hole/NAT, a group of pin-holes/NATs and the
communication/connection between a midcom agent and a middlebox.

I personally liked the term "flow" for an individual thing, and the term
"session" for a group of things. However, a many of those present felt that
the term "resource" was best to describe an individual pin hole/NAT. A
"bundle" was suggested for a group of related "resources".

So here goes.

Resource:
A resource is a single instance of a middlebox service for a specific flow
or stream of packets (e.g. a NAT session or a firewall pin-hole). It defines
the information necessary to identify incoming packets that are associated
with the resource and the actions required to dispose of the packets
(forward them on or drop them). Note that a service may consist of multiple
functions. For example, a single resource could include both the NAT and
firewall functions.

Resource Bundle:
A resource bundle is a group of resources that have been associated together
by the application via the midcom agent, which uses the midcom protocol to
establish the grouping in the middlebox.

How's that?

cheers,
(-:bob

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

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

---

From: "Michael W. Condry" <[email-masked]>
Date: Tue, 07 Aug 2001 07:09:13 -0700

We need to align several groups here including WEBI, OPES and
possibly CDI. Can you send out this to all?
>establish the grouping in the middlebox.

Michael W. Condry
Director,  Network Edge Technology

---

From: Scott Brim <[email-masked]>
Date: Wed, 8 Aug 2001 10:11:14 +0100

> functions. For example, a single resource could include both the NAT and

Thanks for getting this started.  Naturally I don't like your choices
:-).  If you want to get serious about defining terms, which can quickly
become a rathole ...

A resource is an instance of a service?  I would think the service is
the act of translation, or of forwarding, and a resource is something
which makes it possible to provide the service.  The resource is the
ruleset.  Which makes me think the word "resource" isn't going to help
with clarity.  How about "ruleset"?

A "flow" *is* a stream of packets.  We have talked about microflows,
macroflows, and aggregated flows for years.  No need for the redundancy.  

A "session" usually refers to something with endpoints.  The NAT thing,
the ruleset we're talking about is a bit of state at a single point in
support of communications through it, not the communications itself.
How about a NATting or a NAT ruleset or a NAT translation bundle or ...?

So modifying what you have above: "A ruleset is an embodiment of a
single instance of a middlebox service for a specific flow (e.g. a
firewall pinhole).  It defines the information necessary to identify
incoming packets as associated with the resource and the actions
required to dispose of the packets (forward them on, with or without
translation, or drop them).  Note that a ruleset may consist of multiple
functions.  For example, a single ruleset could include both the NAT and
firewall functions."

> establish the grouping in the middlebox.

Ruleset would cover this too.  We could have a single "rule" but I doubt
we'd ever use it.

..Scott

---

From: Paul Sijben <[email-masked]>
Date: Wed, 08 Aug 2001 11:56:55 +0200

I had the feeling that in some MIDCOM writings SESSION was used as a
shorthand for REGISTRATION SESSION. Which is fine as long as we all agree.
Since we don't a synonym is needed for this.

In my mind: 
- a flow is the thing you open the pinhole for
- an aggregate is a bunch of flows.

Paul

-- 
Paul Sijben              Tel:+31 356874774 
Lucent Technologies      Fax:+31 356875954
Forward Looking Work     
Huizen, The Netherlands  http://voip.nl.lucent.com/~sijben (internal)

---

From: "Bob Penfield" <[email-masked]>
Date: Wed, 8 Aug 2001 07:10:15 -0400

> with clarity.  How about "ruleset"?

I too do not really like the term "resource". I think ruleset is better. In
our development, we have been calling this thing in the middlebox a "flow
specification".

> How about a NATting or a NAT ruleset or a NAT translation bundle or ...?

Actually, I got the term "NAT session" from RFC 2663.

> functions.  For example, a single ruleset could include both the NAT and

The phrase "as associated with a resource" in the second sentence should be
removed OR the word "resource" changed to "ruleset".

> Ruleset would cover this too.  We could have a single "rule" but I doubt

I still think we need a separate term for this because it is not a ruleset
itself, but a set of rulesets. The rulesets for the individual flows might
be associated together as the midcom agent establishes them, or as a
separate action after the individual rulesets were created. From that point
on, the midcom agent may make requests for a specific ruleset or for the
bundle as a whole. With SIP there are lots of cases where the application
needs to add, remove, or modify individual rulesets within a group. In SIP
words: add, remove, or modify RTP streams within a SIP session.

We could call it a ruleset group or ruleset bundle. I envision that a
middlebox would instantiate a bundle as just a set of pointers to the
rulesets it contains. I realize that is a middlebox implementation choice,
but I'm using it as an example of how it might be implemented.

The protocol needs to support an identify for a ruleset and an identifier
for the group too so that the midcom agent can request actions on a given
ruleset or on the whole group. These identifiers may be given out by the
middlebox or defined by the midcom agent.

(-:bob

---

From: Mark Duffy <[email-masked]>
Date: Wed, 08 Aug 2001 09:16:41 -0400

Hi,

I think by bundling so much into one conceptual item (resourse aka ruleset)
we will make our job harder.  I would view this thing as being composed of
several important subcomponents that also need to be named:

1.  a specification for what packets the rule is to match (the
5/6/7/whatever-tuple of source/dest address, etc.)
2.  a list of middlebox service actions to be applied (e.g.
pass/drop/nat/etc).
(Each of the above 1 and 2 might also contain other auxiliary attributes
such as expiration time, and/or such attributes might belong to the
resource/ruleset as a whole.) 

In fact, Bob calls out those components but does not name them.  I suggest
we need some terminology for those, perhaps resource-descriptor and
resource-action (or ruleset-descriptor, ruleset-action).

Relative to Bob's 7 Aug msg re "resource (p.k.a. pin-hole) operations"
which proposes additional operations such as create and delete, I would
suggest there should be operations to add/delete ruleset-descriptors and
ruleset-actions to rulesets.

I do agree we also need the concept resource-bundle (or ruleset-bundle or
foobar-bundle).

--Mark

---

From: Scott Brim <[email-masked]>
Date: Wed, 8 Aug 2001 16:21:50 +0100

> Actually, I got the term "NAT session" from RFC 2663.

I can't find it there.  A session in 2663 still has endpoints, etc.  Is
this a moot point now?

> removed OR the word "resource" changed to "ruleset".

I like taking it out entirely.

> middlebox or defined by the midcom agent.

OK, any of this is fine with me.  I was mainly concerned with "resource"
in the previous version.  

Thanks ... Scott

---

From: "Bob Penfield" <[email-masked]>
Date: Wed, 8 Aug 2001 19:23:19 -0400

----- Original Message -----
From: "Mark Duffy" <[email-masked]>
To: "Bob Penfield" <[email-masked]>; "midcom mail-list"
<[email-masked]>
Sent: Wednesday, August 08, 2001 9:16 AM
Subject: Re: [midcom] pin-holes, sessions and flows, oh my!

> resource-action (or ruleset-descriptor, ruleset-action).

I like this.

> ruleset-actions to rulesets.

I'm afraid I don't know what value a descriptor is without actions (at least
action=drop) and even less what an action without a descriptor for it.
Besides I think this is getting too deeply into the middlebox.

I would say we also need a "modify" operation to change the actions for a
ruleset. This might involve adding or removing actions from a ruleset.

---

From: Mark Duffy <[email-masked]>
Date: Thu, 09 Aug 2001 09:02:18 -0400

At 07:23 PM 8/8/01 -0400, Bob Penfield wrote:
...
>Besides I think this is getting too deeply into the middlebox.

Bob, I agree with you on the above point.  The original point I intended to
make was that the MA should be able to manipulate the descriptor and
actions independently, to whatever extent that make sense.  I think your 2
lines below capture that fine.

---

From: Scott Brim <[email-masked]>
Date: Sat, 11 Aug 2001 22:31:39 +0100

> resource-action (or ruleset-descriptor, ruleset-action).

As Dave Oran said, there are 20 years of packet filtering work we can
call on (which I haven't investigated).  He -- I assume he was
representing tradition -- called them matching rules and transform
rules.  I'm willing to call them anything you want.  This is
terminology, this goes in the Framework.  I think those who are serious
about the semantics of rulesets in the protocol ask Dave what he had in
mind.

> ruleset-actions to rulesets.

I think an action is meaningless without a descriptor, and don't see any
benefit in making it possible for an agent to say "install this
descriptor please" with no associated actions.  I suggest that every
request must include the complete descriptor it relates to, but can
add/delete actions.

> I do agree we also need the concept resource-bundle (or ruleset-bundle or

Is this more than a descriptor that matches an aggregate?  Do you want
the middlebox to maintain lists of unrelated rulesets?  As you saw in
previous mail I'm uncomfortable with that because I don't think it helps
the agent appropriately, and burdens the middlebox in new ways.

..Scott

---

From: Mark Duffy <[email-masked]>
Date: Mon, 13 Aug 2001 12:17:28 -0400

Hi Scott, see below ...

At 10:31 PM 8/11/01 +0100, Scott Brim wrote:
...
>request must include the complete descriptor it relates to, but can

Yes, Bob Penfield had the same reaction and I told him I agreed ...   The
original point I intended to make was that the agent should be able to
manipulate the descriptor and actions independently, to whatever extent
that make sense.  I think add/delete actions to an existing descriptor
covers it just fine.

>the agent appropriately, and burdens the middlebox in new ways.

I see it as a useful but certainly not essential feature of the protocol
that the agent can identify to the mb that multiple pinholes belong to a
grouping such that the agent can then operate on them in bulk, say, delete
them all at once.  Presumably the agent posesses some application
intelligence that these pinholes bear some relationship to one another.  

Whether we require such a feature in the protocol should perhaps be one of
the discussion items.  I don't recall who if anyone asked for it.  The
recent discussion seesm to have originated with Bob Penfield proposing a
term for referring to this concept.

-Mark

---

From: Scott Brim <[email-masked]>
Date: Mon, 13 Aug 2001 13:47:47 -0400

> term for referring to this concept.

I'd like to hear people's requirements for atomic execution and how
flexible it needs to be.  For example, does the agent need to be able to
say "please create this and delete that" in such a way that if the first
doesn't happen the second must not either?  Is an aggregate delete
request, with the possibility of mixed results, satisfactory?

On the other hand it would also be good to limit discussion to just a
few requirements at a time (nudge nudge).

---

From: Andrew Molitor <[email-masked]>
Date: Mon, 13 Aug 2001 15:38:17 -0500 (CDT)

> request, with the possibility of mixed results, satisfactory?

	I think it's necessary to do a set of policy "adds" or "creates"
which either succeed or fail together. I think it's also necessary to
be able to delete an aggregate the same way.

	It's not at all obvious to me that it's neccessary to handle adds
and deletes within the same atomic transaction.

	It's also not obvious to me that this makes implementation
any easier, but if it does for someone -- great!

	There are probably many operations which can be handled
non-atomically. Only operations which affect the actual handling
of data traffic passing through the middlebox really need the
atomic-transaction-bundle concept. Even deletes don't really need
a bundle of operations, at the MIDCOM protocol level, a single
operation 'delete all the stuff with this ID atomically' would
probably suffice.

---

From: Jiri Kuthan <[email-masked]>
Date: Tue, 14 Aug 2001 10:47:35 +0200

What you suggest seems to me to exceed requirements and run into protocol
specification. The minimum midcom protocol operations that seem required to 
me are request for opening/closing pinholes and querying/releasing NAT 
translations.

One might implement the same thing in a variety of ways. For example, I might
implement the same behaviour as you describe using a "set state" and
"release state" operation where "set" is used to communicate and
set full per-flow state (new or existing). There are certainly some
designers who would prefer this "set-full-state" approach to "delta-operations" 
as it features higher robustness.

Anyway, I see requirements for robustness and the operations above.
How the protocol exactly looks like is TBD.

-Jiri

---

From: Mark Duffy <[email-masked]>
Date: Tue, 14 Aug 2001 17:00:17 -0400

Jiri, I agree with you and I retract my comment below.  I do not actually
think it is necessary that the midcom protocol  allow manipulating the
descriptor and actions independently.

The way I initially got started on this was that in the framework-03, it
doesn't clearly separate out the _concepts_ of descriptor and action (or
whatever we are going to call them).  I do think we need to separate those
concepts, so that for instance we can use the same descriptor
representation whether it is being used with a FW pinhole or a NAT binding
or whatever.  

I went a little too far in suggesting that the protocol needed to provide a
way to manipulate the concepts separately.

-Mark