[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

relationship of snmpconf to midcom?

Hi -

Does anyone know how this relates to the snmpconf work?

 Randy Presuhn           randy_presuhn@bmc.com
 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: <200101052054.PAA22275@ietf.org>
> From: The IESG <iesg-secretary@ietf.org>
> To: IETF-Announce: ;
> Subject: WG Review: Middlebox Communication (midcom)
> Date: Fri, 05 Jan 2001 15:54:08 -0500
> Sender: scoya@cnri.reston.va.us
> 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.