Subject: WG ACTION: Middlebox Communication (midcom)

From: The IESG <[email-masked]>
Date: Tue, 16 Jan 2001 09:25:15 -0500

A new working group has been formed in the Transport Area of
the IETF. For additional information, contact the Area Directors
or the WG Chair.

Middlebox Communication (midcom)
--------------------------------

 Current Status: Active Working Group
 
 Chair(s):
     Melinda Shore <[email-masked]>
 
 Transport Area Director(s): 
     Scott Bradner  <[email-masked]>
     Allison Mankin  <[email-masked]>
 
 Transport Area Advisor: 
     Scott Bradner  <[email-masked]>
 
 Mailing Lists: 
     General Discussion:[email-masked]
     To Subscribe:      [email-masked]
         In Body:       subscribe your_email_address
     Archive:           ftp://ftp.ietf.org/ietf-mail-archive/midcom
 
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.'

This working group will focus its attention on communication with 
firewalls and network address translators (including translation
between IPv6 and IPv4).  Work will not preclude extensibilty to other
categories of middle box.

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.

This working group will concern itself with an environment that
consists of:

    . 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. This working group will only deal with firewalls 
and network address translators.
 
 Goals and Milestones: 
 
   Aug 01       submit Internet-Drafts of framework, architecture and 
                interfaces documents to IESG for publication as Informational 
                RFCs