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

From: "Cedric Aoun" <[email-masked]>
Date: Wed, 8 Aug 2001 02:13:42 +0100

Bob,
thanks for your efforts.

"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."

CA: 
Instead of NAT session, I suggest to use NAT Bind. We also need to  add "or
other middle box functions"
i.e the proposed text  is :  (e.g. a NAT BIND, a firewall pin-hole or other
middle box functions).
I prefer to modify the end of the sentence to "and packet filtering
functions"
Cedric

---

From: "Bob Penfield" <[email-masked]>
Date: Wed, 8 Aug 2001 06:30:37 -0400

----- Original Message -----
From: "Dr. Carsten Bormann" <[email-masked]>
To: "Bob Penfield" <[email-masked]>
Sent: Tuesday, August 07, 2001 10:45 AM
Subject: RE: [midcom] pin-holes, sessions and flows, oh my!

> > Resource:
> > or stream of packets (e.g. a NAT session or a firewall pin-hole).
>
> No.  A resource is something you get from a Web-Server.  Or the
Web-Server.
> Or the thing you can reserve.  Or the reservation.  Or the human in front
of
> the box :-)
>
> Please use a term that does not already have 1E6 other meanings.  Pin-hole
> at least meant something.
>
> Gruesse, Carsten
>
>

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

---

From: "Sanjoy Sen" <[email-masked]>
Date: Wed, 8 Aug 2001 19:39:31 -0500

> 
> 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).
 
> 
> 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).
> 

I support this separation. Maybe we can call item # 1. Flow descriptor
(because of their end-2-end nature) and item # 2. Resource-action

---

From: John LaCour <[email-masked]>
Date: Thu, 9 Aug 2001 06:46:46 -0700

I don't like using session mostly for pragmatic reasons.  Its
too easily confused to mean many different things.

I like "flow" to describe a stream of traffic in one direction
between end-points.

"Bundle" adequately describes an aggregation of flows.

I think we need to clear on the difference between 
middlebox services/functions/capabilities and the
instance of that capability having been implemented
with specific parameters, presumably as requested by a MIDCOM
agent.  I like using "capability" to describe the things
(services, functions).

Another separate thing to describe is the request that a
capability be implemented along with the appropriate
parameters, which will change depending on the specific
capability.  I think this is what was called a "ruleset"
which I don't like because I find it tends to get confused
with policies.

-John

> -----Original Message-----
> From: Bob Penfield [mailto:[email-masked]]
> Sent: Tuesday, August 07, 2001 5:40 AM
> To: midcom mail-list
> Subject: [midcom] pin-holes, sessions and flows, oh my!
> 
> 
> 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:
> 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]
> 
> 
> 
> 
>

---

From: "Sanjoy Sen" <[email-masked]>
Date: Tue, 14 Aug 2001 13:17:37 -0500

> From: Scott Brim [mailto:[email-masked]]
> Sent: Monday, August 13, 2001 12:48 PM
> To: midcom mail-list
> Subject: Re: [midcom] pin-holes, sessions and flows, oh my!
> 
> 
> 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).
> 

I support the concept of ruleset-bundle (or whatever-bundle) &
ruleset-bundle-id, if this applies to RELATED rulesets. There should be
operations targeted to the bundle (i.e. to ALL rulesets within the bundle)
and there can be (micro)operations aggregated within a message (e.g., a
single UDP message) which are targeted individually to each rule-set within
a bundle. However, I do not see it necessary (at least, at this stage) to
impose any dependency between the micro-operations within a message. 

Sanjoy