Middlebox Communication (midcom) Charter

2.8.10 Middlebox Communication (midcom)

NOTE: This charter is a snapshot of the 61st IETF Meeting in Washington, DC USA. It may now be out-of-date.

Last Modified: 2004-09-29

Chair(s):

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: http://www.ietf.org/mail-archive/web/midcom/index.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.
Done		An analysis of the existing mibs and initial list of mibs (or portions of mibs) that need to be developed submitted to WG
Done		Semantics document submitted to IESG for publication as informational RFC
Done		Initial mibs ID submitted
Jun 04		Mib documents submitted to IESG

Internet-Drafts:

draft-ietf-midcom-protocol-eval-06.txt

draft-ietf-midcom-semantics-08.txt

draft-ietf-midcom-mib-03.txt

Request For Comments:

RFC	Status	Title
RFC3303	I	Middlebox Communication Architecture and framework
RFC3304	I	Middlebox Communications (MIDCOM) Protocol Requirements
RFC3489	PS	STUN - Simple Traversal of UDP Through Network Address Translators

Current Meeting Report

Minutes of the midcom session at IETF 61
----------------------------------------

Washington, DC, USA, Tuesday, November 9 at 1300-1400

The meeting proceeded as per agenda from agenda bashing through brief mention of three docs currently in RFQ Editor Queue. The only substantive matters during the course of the meeting were the following:

In Juergen's update on MIB progress relative to ~~.mib_03.txt, he reported an Open Issue around session table. He offered to go into details, but there were no takers to drill into the specifics of this despite Juergen's invitation. The item is reportedly in Wes' hands. As Wes was not present, no commitment from him was available at meeting time.

Next, Suresh spoke on an Open Issue regarding address tuples in MIDCOM scenarios. When the topology is

endpoint-A0 .. A1-middle box-A2 .. A3-endpoint

Dispute is wrt input parameters (a0,a3) vs (A0, A1) or (A2, A3) Suresh explains: Semantics I-D (A0, A3), most common case, A1 = A3 -- i.e. a0,a3 and a0, a1 have identical values. A series of questions did not clarify matters. Suresh claims a0,a1 defines session terminal points, chair and others saw issue as a0,a3 as session terminal points.

Chair asked Suresh to describe a failure scenario to clarify matters. He provided Twice NAT case as example. Conclusion: is there's no consensus on the semantics here. Item is to be directed to mailing list. Suresh indicated that this issue was not expected to be amenable to consensus in the course of a meeting. It will go to list, and Suresh will initiate thread, including clear scenarios.

Idempotency:

Lifetime can have I failures. SNMP introduces some wrinkles around e.g. lifetime extension requests. SNMP can re-send extension requests in cases where requests are lost, resulting in longer than intended openings. Recommendation: Reduce retransmit time to below smallest lifetime extension request time. Alternatively, suppress retransmit altogether. This solution places burden on requestor to decide what to do as they will be informed immediately upon message loss.

Action items: Adding section 7.2 Final decision on session table vs smnp notification mib Add further recommendation on avoiding I problems (see above) Change from A0,A3 semantics. Proposal was to do this by next mtg. But Chair says this is too long. Let's get this resolved ASAP. Conclusion is Doc is to be set by next mtg. Suresh will get his notes out to list w/in the next couple of weeks. It was observed that only a couple of people had read the MIB doc.

Slides

Agenda