2.8.8 Middlebox Communication (midcom)

NOTE: This charter is a snapshot of the 51st IETF Meeting in London, England. It may now be out-of-date. Last Modified: 31-Jul-01

Chair(s):

Melinda Shore <mshore@cisco.com>

Transport Area Director(s):

Scott Bradner <sob@harvard.edu>
Allison Mankin <mankin@isi.edu>

Transport Area Advisor:

Scott Bradner <sob@harvard.edu>

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 '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

Internet-Drafts:
No Request For Comments

Current Meeting Report

Minutes of midcom working group at 51st IETF Meeting London, England
Friday, August 10, 2001, 9:00-11:30

Chaired by Melinda Shore (mshore@cisco.com)
Reported by Mary Barnes (mbarnes@nortelnetworks.com) and Cedric Aoun (cedric.aoun@nortelnetworks.com), edited by Melinda Shore

Status update/working methods:
* Neither document editor was able to be present.
* Both docs are supposed to be in last call this month.
* Framework document was in last call, had to be stopped due to issues raised.
* Issues (showstoppers) need to be raised ASAP. 4 people need to object for consensus not to be agreed.

Relationship to OPES - Open Pluggable Edge Services (Michael Condry)
--------
OPES is about building application level services between where the content starts and where the content ends (both IP endpoints), typically web services. The working group is looking at callout protocols that go to something like an ALG. Does service and ships elsewhere. Will ensure that overlap with MIDCOM is cross pollinated. OPES is looking at application middleboxes, while MIDCOM is looking at transport middleboxes.

Example:
Presentation services at the edge of the network (close to the "consumer")

Framework document (discussion led by Jiri Kuthan):
--------
Current Issues:
There's a great deal of terminology that isn't agreed upon. We will form a design team

There's currently a requirement for rule "ownership. The intent is to keep someone from closing someone else's pinhole. Some folks want multiple owners to handle takeover-type scenarios.

The ensuing discussion centered around the following points/questions:
1) is "ownership" useful"
2) what is the basis of ownership?
3) what is the underlying model (file locking vs. authorization)
4) is this the correct robustness model?

Jiri Kuthan will develop some text around the ownership question and submit it to the list.

Another unresolved issue is whether the MIDCOM protocol will be peer-to-peer or client/server. The consensus was that it will be client/server.

A discussion of identifiers/handles for the open "pinholes" and "sessions" raised additional questions about how pinhole requests should be specified. There was a suggestion that the things that are created on the middlebox (firewall pinholes, NAT mappings) may be identified by the contents of the things themselves (such as a 5-tuple describing a firewall pinhole) or by an identifier allocated by the middlebox. Concerns included how (and whether) to aggregate, directionality, whether allocation and open are separate operations, and whether or not atomic actions across multiple middleboxes should be supported. The group concluded that there was a need for a design team, to be shepherded by Christian Huitema. Their job is to restate the problem more clearly.

Jiri asked if there's an issue with fragmented packets traversing the middlebox. The consensus was that this is not the working group's problem.

The working group has been unable to resolve the question of how network topology should be handled by the midcom agent. Because we've had so little progress despite extensive discussion, the chair proposed forming a design team. Ted Hardie suggested that instead we should use the old IETF contest of champions approach, in which champions write drafts describing their solution to the problem. The chair agreed. The Area Director present, Scott Bradner, agreed with this approach and indicated that the Transport Area Directors will assist in evaluating the proposals.

Someone asked why we have a design team for one problem and a contest for another area. The design teams are for work that's currently within the charter and on which there's fundamental agreement about what we're doing. The contest of champions approach is being used for the topology question because there is not even basic agreement on what the question is, and there's a need to define the problem.

Requirements document (discussion led by Paul Sijben)
--------
Status:
* Information get togethers have given a lot of input

* Scott Brim has been maintaining a list of requirements that are either implicit in the framework document and are unresolved or are explicit and unresolved.

The discussion in the meeting focused on 1) the structure of working group deliverable, and 2) trying to get common understanding on remaining issues (based on Scott's list)

There was general agreement that there were far too many requirements, although Graham Travers disagreed with trying to place a limit on the number of requirements. Christian Huitema said that the document should be about six pages long.

Paul Sijben said that the document should not be simply a bulleted list of requirements. It was reiterated that it shouldn't be necessary to have no requirements in the framework document and no discussion in the requirements document, but that some seepage was inevitable. Scott Bradner said that a list of requirements without explanation is almost useless, and that a thick document is almost useless. If it takes more than a paragraph then it's probably too long.

Terminology needs to be defined in the framework document and then used consistently in both documents.

Unresolved Issues:
Elliot Lear is preparing the definition of a pinhole. Elliot said that there were a bunch of requirements describing the purpose of a pinhole with regard to associated resources, and this should roll up to policy. He's come come up with a general description but it may be misconstrued as describing the protocol. The only information in the protocol should be that necessary to describe the policy. An extensive discussion of which elements to include, including directionality, left the question still unresolved.

The issue of whether or not agents must be known to endsystem applications has been closed, and the text has been deleted.

Requirement R18 from Scott Brim's list of unresolved issues says that the middlebox MUST NOT alter packet information unless it appears in the packet header. Paul Sijben said taht the reason for the requirement is to have a clear separation of concerns. Objections included that the definition of "header" is unclear. It was pointed out that we cannot put requirements on the middlebox. Dave Oran said that the requirement has no technical content and proposed that it could be rewritten to say that the middlebox is not permitted to write a transformation rule that operates on something that is not specified in a filter. The chair started a poll asking how many people wanted the requirement gone completely (some), how many people wanted to keep the requirement as is (none), and how many people want to discuss Dave Oran's proposal. The last was interrupted by Scott Bradner, who said that the requirement would not go through the IESG. It was therefore dropped.

* Requirement R3a: The MIDCOM protocol MUST support communication between multiple MIDCOM agents and multiple middleboxes.

Someone said that the requirement should be that one agent may open a pinhole and another may close it, and that the requirement needs to be reworded. Scott Brim responded that it wasn't intended for two agents working on the same pinhole, but that a middlebox can talk to more than one midcom agents (and tell the difference). Scott then said that it should either be tossed out or split in two. It was agreed that it should be split into two requirements.

* Issue: There must be ownership of resources/pinholes, and there must be a way to transfer this ownership from one agent to another

Christian said to leave it to the policy server. There is authorization, but it's not expressed in terms of ownership. Someone responded that we don't want it expressed in terms of policy, and proposed that agents should coordinate ownership outside the protocol. Dave Oran asked whether ownership is a 1) security or 2) mutual exclusion property. Paul said it's not about mutual exclusion. Dave then suggested that this is a capability-based authorization, although he thinks that capabilities are a bad idea. Christian said that he didn't like the implications of ownership transfer. Jiri is going to work on some alternate text.

Slides

Agenda
'draft-ietf-midcom-requirements-02'+1