Subject: relationship of snmpconf to midcom?

From: Randy Presuhn <[email-masked]>
Date: Fri, 5 Jan 2001 16:15:46 -0800 (PST)

Hi -

Does anyone know how this relates to the snmpconf work?

 -------------------------------------------------------
 Randy Presuhn           [email-masked]
 Voice: +1 408 546-1006  BMC Software, Inc.  1-3141
 Fax:   +1 408 965-0359  2141 North First Street
 http://www.bmc.com/     San José, California 95131  USA
 -------------------------------------------------------
 My opinions and BMC's are independent variables.
 -------------------------------------------------------

> Message-Id: <[email-masked]>
> From: The IESG <[email-masked]>
> To: IETF-Announce: ;
> Subject: WG Review: Middlebox Communication (midcom)
> Date: Fri, 05 Jan 2001 15:54:08 -0500
> Sender: [email-masked]
> Status: RO
> 
> A new IETF working group has been proposed in the Transport Area.
> The IESG has not made any determination as yet. 
> 
> The following Description was submitted, and is provided for
> informational purposes only:
> 
> Middlebox Communication (midcom)
> --------------------------------
> 
>  Current Status: Proposed Working Group
>  
> Description of Working Group:
>  
> As trusted third parties are increasingly being asked to make policy
> decisions on behalf of the various entities participating in an
> application's operation, a need has developed for applications to be 
> able to communicate their needs to the devices in the network that 
> provide transport policy enforcement. Examples of these devices include 
> firewalls, network address translators (both within and between address 
> families), signature management for intrusion detection systems, and 
> multimedia buffer management. These devices are a subset of what can be 
> referred to as 'middle boxes.'
> 
> Decomposing applications requiring policy decisions by removing 
> application logic from the middle box and instead providing a 
> generalized communications interface provides a number of benefits, 
> including improved performance, lower software development and 
> maintenance costs, improved ability to support traversal of packet 
> filters by complex protocols, easier deployment of new applications, and 
> the ability to consolidate management functions.  For example, by moving 
> stateful inspection of protocols such as H.323 and SIP out of firewalls, 
> it is possible to improve performance and scalability and reduce 
> development and costs.
> 
> The elements of this architecture include
> 
>     . one or more middle boxes in the data path
> 
>     . an external requesting entity
> 
>     . a policy entity for consultation purposes when the
>       requesting entity is untrusted.
> 
> The requesting entity may be trusted or untrusted. In the case where it 
> is trusted, the middle box will treat the request from the entity as
> authoritative.  In the case where it is not trusted, the intermediate
> device will have to verify that it is authorized to complete the 
> request. That authorization could come from a separate or a built in 
> policy server.
> 
> The primary focus of the working group will be the application of this
> architecture to communicating requests between applications and 
> firewalls or NATs.  This will not preclude other uses, and care will be 
> taken to ensure that the framework is extensible.
> 
> The focus of the working group will be the architectural framework and 
> the requirements for the protocol between the requesting device and the 
> middle box and the architectural framework for the interface between the 
> middle box and the policy entity.  In both cases we intend to reuse 
> existing or in process IETF protocols if possible.
> 
> The security of the interfaces will be one of the primary focuses of the
> work, and potential vulnerabilities on the interfaces and in the
> architecture along with defenses against those threats will be 
> identified.
> 
> Discovery of middle boxes is out of scope.
> 
> The deliverables will be
> 
> o a document specifying the architecture and interfaces on
> 
>   . a requesting entity
> 
>   . a middle box
> 
> o a document the requirements for both the
>   architecture and the control language
> 
> o a document describing the requirements for a policy enity
> 
> Once these deliverables are complete, the Area Directors will decide if 
> the working group should be rechartered.  If rechartered the working 
> group could undertake protocol development  or development of profiles 
> of existing protocols.
...

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 08 Jan 2001 10:06:10 -0500

I should be rather surprised if there was any relationship at all.  From 
reading Elliot's notes, Midcom is about defining architecture (and maybe 
even protocols) which get in the middle of the users data streams.  The 
most obvious example is web caches and proxies.  I believe that they also 
include NATs and Applications gateways in the problem space.  None of this 
has anything to do with SNMP or SNMP for Configuration.
Yours,
Joel M. Halpern

---

From: Jon Saperia <[email-masked]>
Date: Mon, 08 Jan 2001 10:19:47 -0500

> has anything to do with SNMP or SNMP for Configuration.

Where configuration takes place (and most things have some basic
configuration) they should be specified using a common standard unless
there is some compelling reason not to do so.

/jon
--

Jon Saperia		     [email-masked]
			     Phone: 617-744-1079
			     Fax:   617-249-0874
			     http://www.jdscons.com/

---

From: Jiri Kuthan <[email-masked]>
Date: Fri, 12 Jan 2001 19:08:09 +0100

What I'm saying now is my understanding of midcom which may or may not be
understanding of a prospective WG, IESG, or whomever else.

The driver behind midcom is the desire to get VoIP and other applications
using session protocols (SIP, RTSP, H.323, ... ) across firewalls
and NATs (and possibly other "middleboxes"). It is difficult unless
the middleboxes understand the applications. Though one may have 
embedded ALGs in such middleboxes, there are scenarios in which
it seems easier to have the application awareness out of them.

This is the scenario midcom is looking at. A protocol is needed 
which allows the application to ask "please, tell me a NAT translation 
that will be applied to my packet voice stream" or "please, open a pinhole 
for the stream in the firewall".

There are, IMHO, two items on the midcom to-do-list: to document this
problem: scope, issues, requirements, etc. Once the problem is understood 
and  documented, the next item will be to show how it can or cannot be 
solved using existing protocols. Meanwhile, I've heard many protocols 
spelled in this context including SNMP, COPS-PR, LDAP, MGCP, .... 

To address some of the technical comments/questions raised previously:
- It will be a requirement that the midcom protocol (whatever it is)
  operates in real-time.
- I do not think that web caches are of primary interest. Firewalls and 
  NATs are.

Those interested in foglamps may check its archive and/or subscribe to
the mailing list:

[email-masked]
To subscribe, send email to [email-masked] with “subscribe foglamps” in the body of message
Archive: http://www.fokus.gmd.de/glone/ietf/foglamps/

Jiri

---

From: Jon Saperia <[email-masked]>
Date: Sun, 14 Jan 2001 09:33:15 -0500

Jiri,

Thanks for your note. It is clear and helpful. The only point I have
been stressing is that the configuration of these middle boxes should be
done with an extant management (SNMP) technology. I have not been
proposing that it be used for the real time application request
functions you describe. In short, I think we are all in agreement.

/jon

> Archive: http://www.fokus.gmd.de/glone/ietf/foglamps/

Thanks,
/jon
--

---

From: Randy Bush <[email-masked]>
Date: Sun, 14 Jan 2001 07:42:45 -0800

> The only point I have been stressing is that the configuration of these
> middle boxes should be done with an extant management (SNMP) technology.

i find this interesting in light of the absense of definition of what is to
be configured.  does everything always look like a nail?

randy

---

From: Jon Saperia <[email-masked]>
Date: Sun, 14 Jan 2001 11:00:58 -0500

> be configured.  does everything always look like a nail?

Your question, presses the usual engineering issue when a new feature is
required. Do you invent something completely new which is hand tailored
for what you are building and thus possibly better suited to that
particular application, or do you take something that exists and
add/modify to it? We can find ample examples of each approach in other
areas of technology that we all work with.

Configuration functions differ in some respects for each technology and
are similar in other respects. Good engineering design practice
suggests that an effort is better served by leveraging those
similarities when possible rather than recoding essentially
similar/duplicate functions. 

/jon
--

---

From: Randy Bush <[email-masked]>
Date: Sun, 14 Jan 2001 10:15:01 -0800

> areas of technology that we all work with.

so we should constrain all measurement and control design problems to the
space that can be solved by an snmp-based solution.  that will certainly
make life simple.

randy