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.
