Current Meeting Report
Slides


2.7.8 Middlebox Communication (midcom)

NOTE: This charter is a snapshot of the 52nd IETF Meeting in Salt Lake City, Utah USA. It may now be out-of-date. Last Modified: 08-Oct-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
Oct 01   submit pre-midcom protocol to IESG for consideration as Proposed
Internet-Drafts:
No Request For Comments

Current Meeting Report

MIDCOM Minutes
Recorded by Tom Taylor and Brian Stucker

MIDCOM met 7:30-10:00pm Monday, December 10. Melinda Shore <mshore@cisco.com> was Chair.

1. Agenda
======

The proposed agenda was accepted without change.

2. Alternative Midcom Approach
(draft-shore-friendly-midcom-00.txt)
====================================
Melinda Shore presented the advantages of using an approach based on the RSVP model.
Open issues:
- doesn't function with mediated signalling (gatekeeper, proxy)
- keying
- protocol selection.

Question: how open is the Working Group to changing its model?

Christian Huitema <huitema@windows.microsoft.com> expressed his opposition to the proposal. The Working Group has had one year of discussion and has arrived at a consensus on requirements. We cannot throw that away. Addressing the proposed use of RSVP as a model, he pointed out that RSVP could never solve the issue of authentication along the path. Moreover, RSVP requires that both ends be aware of each other.

Jonathan Rosenberg <jdrosen@dynamicsoft.com> argued that Melinda was working on a new problem, which should be addressed by a new BOF. There is no single solution to all cases, and her proposal would present issues for third party control.

Cedric Aoun <aoun@nortelnetworks.com> pointed out that route discovery is important, and needs to be part of the midcom solution. Melinda responded that the solutions proposed up to now all involve putting routing information into the agents, and this is a problem.

Further discussion supported the view that Melinda was proposing a new problem which should be handled by a separate Working Group. There was some argument over whether this effort should be sequential or parallel. Scott Bradner, Transport Area Director, provided a final view of consensus: to continue along the lines already established by the Working Group.

3. Rechartering
============

Melinda Shore suggested the next step: we need comparison documents for protocol selection. Cedric Aoun <aoun@nortelnetworks.com> reminded the group of the existence of an analysis of COPS (draft-aoun-midcom-cops-00.txt) and Megaco (draft-sct-midcom-megaco-00.txt). He wondered if discovery could be added as a work item. Cullen Jennings <fluffy@cisco.com> opposed this broadening of the effort. The Chair ruled that the Working Group has not done requirements and framework for discovery, so it is out of scope.

3.1 Pre-midcom
----------

Leslie Daigle presented a number of concerns that the IAB has with the pre-midcom work. At the time of the midcom meeting the IAB was divided and had no consensus position. midcom was to be a topic for the IAB meeting the next day, and they might be able to report an outcome at the IAB plenary Thursday night. The fundamental issue is that the workarounds go around the intended architecture. The key points the WG should be aware of are to recognize that pre-midcom is a short term fix, and to make sure it doesn't get in the way of the target architecture. One major concern is that even pre-midcom solutions will take ages to deploy, and will be around forever once they are deployed.

Rohan Mahy <rohan@cisco.com> asked if the IAB is concerned with operation in the here and now? The response was that the concern is whether the pre-midcom effort will lead to a fix whose cost and lifetime don't merit the effort. The IAB wants to make sure the right 20% of functionality doesn't get done.

Christian Huitema asked if the IAB had a concern that ultimate midcom as opposed to pre-midcom could block IPv6 address deployment. The responder was unable to speak for the IAB at this point. Rohan Mahy asked if SHIPWORM (draft-ietf-ngtrans-shipworm-03.txt) is a concern to IAB. The answer was that SHIPWORM will be discussed.

Eliot Lear <lear@cisco.com> expressed the suspicion that TURN will take longer to implement than people expect. The weighing of concerns may be better done in the IRTF or IAB than in the IETF. Jonathan Rosenberg restated the IAB concern: make sure not too much effort goes into the short-term solution. There is an upper bound to the WG's effort on this item.

Brian Carpenter <brian@hursley.ibm.com> noted that SHIPWORM has the useful property that it preserves layer separation, thereby reducing complexity. We should bear the same principle in mind for other work.

The Chair brought the meeting back to the basic question: how does the WG go forward?

Pete Cordell <pete@tech-know-ware.com> asked if the IAB would decide within the week. The response was that it is hard to assign a probability that the IAB would reach a position quickly.

Allison Mankin, Transport Area Director, reported that there had been some IESG soul-searching on the question of whether the WG should have been given the-Midcom task. The bce of IESG opinion is still that it will have worthwhile results. The Area Directors are looking for the room's opinion: keep pre-midcom in the Working Group or move it out (e.g. relegate to individual RFCs or various other solns). Scott Bradner noted that multiple standards-track RFCs for this problem might not be viewed favourably.

Jonathan expressed fear that if we defer the work application intelligence will continue to be added in NATs and firewalls rather than in a more suitable location.

By show of hands in response to two questions, there was consensus that the pre-midcom work needed to be done, but there was not overwhelming consensus to keep the pre-midcom work item in the midcom working group. The Chair ruled that meeting would continue its agenda on the assumption we keep pre-midcom in the WG, but the decision will be verified on the list. She noted that the pre-midcom work item has proved more difficult than expected -- the original milestone date was October.

4. midcom-Unaware NAT/Firewall Traversal
(draft-sen-midcom-fw-nat-00.txt)
=====================================

Mary Barnes <mbarnes@nortelnetworks.com> presented.

Benefits
--------
- works for enterprise networks
- minimizes the impact and knowledge required in clients
- additions to SIP are limited to a new lightweight SIP PING method and a new Proxy-Require tag
- existing rather than a new protocol is used between the Media Proxy and the SIP proxies
- network configuration for this solution is simple
- Media Proxy has additional potential uses beyond NAT passage
- NAT bindings are not carried in signalling messages.

Issues
------
- solution is SIP-specific
- expensive in terms of network resources
- requires the use of symmetric RTP
- impacts enterprise firewall policy.

The Nortel IPR claim associated with this draft was noted in subsequent discussion.

5. Traversal of non-Protocol Aware Firewalls & NATS
(draft-davies-fw-nat-traversal-01.txt)
==========================================

Steve Davies <sdavies@ridgewaysystems.com> presented.

Benefits
--------

The primary argument offered was that FANTOM is consistent with the long-term midcom solution. The first slide showed the similarity of the FANTOM arch to the expected midcom final result. Steve argued from that similarity that the short and long-term protocols should be the same, implying an easy transition. He stated that the FANTOM solution can be deployed anywhere, and can work with all firewall/NAT combinations.

Issues
------
Requires additional media hops. Midcom will fix that.

An associated IPR claim was noted in subsequent discussion.


6. STUN and TURN
(draft-rosenberg-midcom-stun-00.txt)
(draft-rosenberg-midcom-turn-00.txt)
====================================

Jonathan Rosenberg presented.

STUN Benefits
-------------

- avoid media triangulation
- simpler servers
- additional uses -- discovery, allocation, diagnostics
- new function, useful even after Midcom
- covers items where Midcom has issues: NAT upgrade, virus vulnerability of controller, configuration complexity (residential case)
- IF deployed in symmetric-based enterprise, the advance to full Midcom is easier.
- immune to viruses

STUN Issues
-----------
- does not handle the symmetric case

TURN Benefits
-------------
- simplicity
- limited feature set helps deal with IT concerns

TURN Issues
-----------
- can't run servers -- allows only one inbound association
- can't send to arbitrary places from the same socket

Jonathan indicated that in his view these outweigh the benefits of TURN.
- limitations, but may be useful in specific situations

7. Discussion
==========

7.1 IPR
-------
Scott Bradner clarified the IETF position on IPR. Disclosure is not an issue: in the case of the Sen and Davies drafts, it has been made as required. The decision on adoption of the technology is up to the Working Group.

The Chair asked the authors of the various drafts whether they have IPR disclosures to make. Jonathan Rosenberg and Rohan Mahy said they had none. Mary Barnes referred to the statement in the Semn draft. Christian Huitema indicated the possibility that CalTech may have revealed prior art on its web page two years ago.

7.2 Decision Rules
------------------

The Chair asked what decision rules the group should use to pick a pre-midcom solution. There was agreement that the group should not make an arbitrary choice, and a suggestion that STUN should be part of the final solution. The group needs requirements against which to judge the proposals.

The point was made that identification of different network environments means different solutions have to be combined. Another speaker countered that applications inherit an even more complex environment as a result of making these distinctions.

The Chair suggested that this was a matter of refining scope more than requirements. One question was whether pre-midcom should deal with NATs only, or also firewalls?

The Chair summed up by noting that the midcom framework and requirements are going to the IESG for comment. They will be input to the rechartering discussion. It is probable that pre-Midcom will remain with the Working Group. There was agreement that pre-midcom will include STUN plus whatever falls out of the scope definition.



Slides

FANTOM & Midcom
TURN
Midcom-unaware NAT/Firewall Traversal