2.8.6 Middlebox Communication (midcom)

NOTE: This charter is a snapshot of the 58th IETF Meeting in Minneapolis, Minnesota USA. It may now be out-of-date.

Last Modified: 2003-10-01

Melinda Shore <mshore@cisco.com>
Transport Area Director(s):
Allison Mankin <mankin@psg.com>
Jon Peterson <jon.peterson@neustar.biz>
Transport Area Advisor:
Jon Peterson <jon.peterson@neustar.biz>
Mailing Lists:
General Discussion: midcom@ietf.org
To Subscribe: midcom-request@ietf.org
In Body: subscribe your_email_address
Archive: www.ietf.org/mail-archive/working-groups/midcom/current/maillist.html
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 'middleboxes.'

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 extensibility 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 protocol is extensible.

The working group will evaluate existing IETF protocols for their applicability to this problem, using the framework and requirements documents developed during the working group's first phase as criteria for the evaluation. If a protocol is found to be suitable it will be used as the basis for the development of a middlebox communication protocol. In the unlikely case that one is not found to be suitable, the working group will undertake development of a new protocol.

Discovery of middle boxes is out of scope.

The deliverables will be

o a document evaluating existing IETF protocols for their suitability

o a document specifying a middlebox communication protocol or profile based on the results of the protocol evaluation.

This working group will only deal with firewalls and network address translators.

Ubiquitous deployment of midcom in all middleboxes could take many years. In the interim, a solution is needed that allows applications to operate in the presence of midcom-unaware middleboxes. To support this, the midcom group will develop or document a protocol or approach that allows clients to indirectly obtain address bindings from midcom- unaware middleboxes, through communications with server elements on the public side of the middlebox. The key goals for this effort are rapid delivery of a simple solution (since it is an interim solution), consistency with the midcom framework, and security. In particular, any proposed interim approaches will address (and document) the architectural and pragmatic concerns described in [UNSAF].

Goals and Milestones:
Done  submit Internet-Drafts of framework, architecture and interfaces documents to IESG for publication as Informational RFCs
Done  Submission of STUN document for standards-track publication
Done  Submission of pre-midcom document describing protocol for NAT traversal using relay for standards-track publication
Done  Submission of document evaluating existing IETF protocols against midcom framework and requirements for an Informational RFC.
Jul 03  An analysis of the existing mibs and initial list of mibs (or portions of mibs) that need to be developed submitted to WG
Aug 03  Semantics document submitted to IESG for publication as informational RFC
Sep 03  Initial mibs ID submitted
Dec 03  Mib documents submitted to IESG
  • - draft-ietf-midcom-protocol-eval-06.txt
  • - draft-ietf-midcom-semantics-06.txt
  • - draft-ietf-midcom-mib-analysis-01.txt
  • Request For Comments:
    RFC3304 I Middlebox Communications (MIDCOM) Protocol Requirements
    RFC3303 I Middlebox Communication Architecture and framework
    RFC3489 PS STUN - Simple Traversal of UDP Through Network Address Translators

    Current Meeting Report

    Minutes of the midcom session at IETF58
    Minneapolis, Tuesday, November 11, 2003, 15:45 h - 16:00 h
    Melinda Shore reported on the WG documents status. The semantics 
    document was sent to the IESG.  The protocol evaluation document still in 
    the RFC editor queue.  The MIDOCM MIB document is delayed but 
    Mary Barnes reported on progress of the MIDCOM MIB design.  The MIDCOM MIB 
    analysis document 
    draft-ietf-midcom-mib-analysis-01.txt is being updated.  It is awaiting 
    approval to split FW functionality from the IPSec Policy 
    Configuration MIB.
    Two new issues were raised.  It was questioned whether or not IP address 
    wildcarding is required for A0, and whether or not port ranges larger than 2 
    port numbers are required.
    Out of the design teams, two drafts for the MIDCOM MIB were written as 
    individual submission.  One approach uses explicit relationships to used 
    resources, the other one uses implicit relationships. Currently, merging 
    both approaches is progressing.  Agreements were made about
     - realizing PRR policies on NATs by disabled bindings,
     - realizing PER policies on NATs by NAT sessions (at least in most 
    cases), and
     - the indexing scheme for groups.
    Still under discussion is modeling of policy rules.
    It is planned to have a merged MIDCOM MIB proposal by Nov 27. Then 
    interim feedback from a MIB doctor will be requested. Completion of the I-D 
    is envisioned for February 2004 which would allow submitting the 
    document to the IESG around April