2.8.8 Middlebox Communication (midcom)

NOTE: This charter is a snapshot of the 56th IETF Meeting in San Francisco, California USA. It may now be out-of-date.

Last Modified: 2003-02-03

Melinda Shore <mshore@cisco.com>
Transport Area Director(s):
Scott Bradner <sob@harvard.edu>
Allison Mankin <mankin@psg.com>
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 '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.
MAR 03  An analysis of the existing mibs and initial list of mibs (or portions of mibs) that need to be developed submitted to WG
MAY 03  Initial mibs ID submitted
MAY 03  Semantics document submitted to IESG for publication as informational RFC
SEP 03  Mib documents submitted to IESG
  • - draft-ietf-midcom-stun-05.txt
  • - draft-ietf-midcom-protocol-eval-06.txt
  • - draft-ietf-midcom-semantics-01.txt
  • Request For Comments:
    RFC3304 I Middlebox Communications (MIDCOM) Protocol Requirements
    RFC3303 I Middlebox Communication Architecture and framework

    Current Meeting Report

    IETF 56 MIDCOM minutes, reported by Tom Taylor 
    MIDCOM met for one hour on Tuesday afternoon, 18 March 2003.  Melinda 
    Shore <mshore@cisco.com> chaired the meeting.
    1. Agenda-bashing
    The agenda was accepted as proposed.
    2. Status update
    STUN has now been published as RFC 3489.
    The protocol evaluation document is scheduled to be through WG last call in 
    May 2003, and we appear to be on schedule.
    It looks like first draft of the MIDCOM MIB document is pretty well on 
    schedule (March 2003).
    3.  MIDCOM MIB
    MIDCOM is operating on the hypothesis that the MIDCOM transport 
    protocol will be SNMPv3.  A design team consisting of Mary Barnes 
    <mbarnes@nortelnetworks.com> (Editor), David Harrington 
    <dbh@enterasys.com>, and Martin Stiemerling 
    <Martin.Stiemerling@ccrle.nec.de> has begun work on the MIDCOM MIB.
    Mary presented the initial report on the status of the design team's work.  
    The team is generally agreed on the applicability of the NAT MIB to the 
    MIDCOM work.  It has been looking at other MIBs (listed in Mary's 
    charts) to see which modules or parts thereof meet the MIDCOM 
    One of the charts showed the sets of MIBs potentially applicable at the 
    middlebox, but also at the MIDCOM policy decision point (PDP).  Several 
    policy-related MIBs are applicable at the PDP and are of importance to the 
    successful operation of MIDCOM, but are outside the scope of the WG.
    Juergen Quittek <Quittek@ccrle.nec.de> asked what aspects of the Policy 
    Coordination and Policy MIBs the design team would tackle.  David 
    Harrington took the floor to respond.  [I missed something here] David 
    recommends using templates rather than a script base.
    Juergen asked whether the diagram (which showed a "MIDCOM Interface" 
    function sitting atop a number of service configuration MIBs relating to the 
    actual middlebox device operation) indicated that the MIDCOM MIB sits on top 
    of the service configuration MIBs?  Mary Barnes responded that MIDCOM is 
    viewed as a coordination function amongst these MIBs.  Subsequent 
    discussion drew a clarification that the "Application Requests" from the 
    MIDCOM agent to the middlebox are carried by SNMPv3.
    The design team's goal is to make a baseline document available 
    shortly.  The team needs immediate feedback before they dig more deeply.
    At this point David Harrington took discussion in a new direction.  He 
    noted that the question has been asked: why MIDCOM does not use XMLConf 
    (XML-based configuration) instead of SNMP?  It is clear that operators do 
    not use SNMPv3 to do configuration now.  There is a concern that 
    operators won't turn on SNMPv3 SETs to allow MIDCOM to work.  The IESG 
    response to this proposition has been to suggest that thought be given to 
    the general situation before doing detailed MIDCOM MIB work.
    Based on the outcome of the netconf BOF at this meeting, prospects look 
    good for XMLConf to go ahead.  Melinda asked what would make us think that 
    operators will turn on XMLConf.  Jonathan Rosenberg 
    <jdrosen@dynamicsoft.com> stated that they would do so because 
    XMLConf would be much cheaper to run.
    David Harrington noted that we could think of the current work as design of 
    an information model before doing a data model.  The work won't be wasted if 
    care is taken by the XMLConf design group to allow reuse of existing 
    information modelling.
    Bert Wijnen <bwijnen@lucent.com> offered the opinion that some of the 
    MIDCOM MIB work going forward may be wasted.  Definitely operators are not 
    interested in using COPS/COPS-PR, and are using CLI rather than SNMP 
    forconfiguration.  Maybe 60-70% of the people in the room at the netconf BOF 
    had read the XMLConf document -- an amazingly high proportion compared with 
    typical IETF participation.  There was substantial operator support for 
    development of an XMLConf approach to configuration.  Bert, as 
    Operations Area AD, does not require writable objects in MIBs -- a change in 
    heart from two years ago.  The MIDCOM WG should take this into account. 
    Melinda Shore confessed herself a bit surprised.  Bert responded that an 
    Operations Area open meeting is scheduled for Thursday.  There will 
    probably be an AD statement on the configuration topic then.
    Jonathan Rosenberg expressed a concern over whether the MIDCOM 
    information model would be reusable.  Basically we have a good 
    understanding of the problem now.  He doesn't want to do work that will be 
    obsolete.  What are the detailed reasons that operators do not enable 
    SNMPv3 SET?  Bert replied that there was no point in going into the 
    reasons; we just have to accept the fact.  The operators are not using it.  
    In contrast, the cable and ATM worlds do use it.
    Christian Huitema <chuitema@microsoft.com> reminded the meeting that the 
    original perceived MIDCOM target was enabling enterprise 
    applications to run across firewalls.  The focus is on enterprise and 
    real-time operations.  This is in some contrast to configuration, which is 
    typically a batch process.  Bert agreed that netconf is addressing a 
    different environment.  Christian remarked that the main problem is to 
    convince enterprise network operators to allow a server to punch holes in 
    the firewall in real time.
    Jonathan Rosenberg remarked that SNMP was selected as the MIDCOM 
    candidate partly because it would be there anyway.  It looks like this 
    premise was dubious.  David Harrington replied that SNMP would still be 
    there for monitoring.  XMLConf will be there for configuration.  The 
    XMLConf group would like to reuse the MIB modules which were designed with 
    config in mind.  The implication is that XMLConf will be compatibile with 
    SNMPv3.  Jonathan rejoined that we are still facing a situation of 
    reduced motivation to use SNMPv3.
    Marcus Brunner <...> responded that we already have a pretty good idea of 
    the information that has to go back and forth (the semantics).  We can 
    fairly easily create an SNMP module now, then use the same source for XML.  
    Juergen Quittek agreed that it should be easy given the semantics 
    already defined.  He sees it as worthwhile to do the MIB now.
    Brian Carpenter <...> remarked that SNMPv3 SETs won't work too well in 
    enterprise environments with internal firewalls/NATs.  There is a 
    chicken-and-egg situation where MIDCOM would be needed to enable MIDCOM.  
    David Harrington noted that SNMPv3 itself will help to some extent.
    Brian stated that there is a job of persuasion to do before operators will 
    allow MIDCOM to run.  Tom Taylor added that it is clear that as part of the 
    task of persuading operators to allow MIDCOM to function, someone has to do a 
    good job of designing the policy controls to keep applications within 
    their intended limits when MIDCOM is present.
    4. Semantics document
    Martin Stiemerling reviewed the latest changes to the MIDCOM semantics 
    draft.  The main one has been to downgrade the role of groups.  He has 
    alaso made some revisions to the conformance statements.
    Open issues:
       Is wildcarding of IP addresses needed?
       More details on capability information sent by middlebox during 
    session establishment.
       Whether explicit support for other protocols besides UDP and TCP is 
       Whether the middlebox should offer a choice of encryption methods for 
    authentication during session establishment.
       Fuller security considerations.
       Possible addition of agent-supplied parameters to restrict usage of 
    Martin presented an explanation of the requirement for the Policy Rule 
    Reserve (PRR) operation.  As subsequent discussion showed, the 
    rtequirement for address reservation got confused with the IP 
    wildcarding issue.
    Jonathan Rosenberg pointed out that PRR as shown in Martin's example won't 
    work with early media.  IP wildcards are essential.  Jonathan was 
    supported by Christian Huitema, who invoked the principle that one 
    shouldn't embed policy decisions (prohibition of cones in favour of 
    pinholes) in the design of the protocol.  Jonathan further noted that 
    forking could also result in blocked media if wildcarding is not 
    Juergen Quittek advanced the counter-argument that if IP address 
    wildcarding is allowed, it will always be used, and there will be no 
    incentive to restrict firewall openings to the minimum width 
    necessary.  Christian Huitema repeated his point that this was a policy 
    issue which should not be settled in advance by the protocol.
    Bob Penfield argued that the key point is that the agent needs to handle the 
    two directions of media flow separately.  Reservation is appropriate for the 
    outgoing direction, but wildcarding is required for the incoming flow -- 
    particularly since the source of early media can differ from the source of 
    media sent after answer.
    5. Wrapup
    The Chair terminated discussion at this point, as the meeting time had 
    expired.  As usual with MIDCOM, there will be discussions with the IESG on 
    how to proceed.


    MIDCOM Protocol Semantics