NOTE: This charter is a snapshot of the 50th IETF Meeting in Minneapolis, Minnesota. It may now be out-of-date. Last Modified: 14-Mar-01
Melinda Shore <mshore@cisco.com>
Scott Bradner <sob@harvard.edu>
Allison Mankin <mankin@east.isi.edu>
Scott Bradner <sob@harvard.edu>
General Discussion:midcom@ietf.org
To Subscribe: midcom-request@ietf.org
In Body: subscribe your_email_address
Archive: ftp://ftp.ietf.org/ietf-mail-archive/midcom
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.
Aug 01 |
|
submit Internet-Drafts of framework, architecture and interfaces documents to IESG for publication as Informational RFCs |
· Middlebox Communication Architecture and framework
· Requirements for the MIDCOM architecture and control language
MIDCOM Meeting Minutes, 50th IETF
Chair: Melinda Shore
Minutes: Ted Hardie
March 22, 2001
Agenda:
Agenda Bashing
Update on Working Group Status
Discussion of Framework Draft
Discussion of Requirements Draft
AOB
Agree on next steps.
Resulting Action Items:
Both sets of document authors will present new versions of their drafts on the most aggressive schedule they can support. Those documents will eliminate references to the functions inside the middlebox and focus on the use of the midcom protocol.
Members of the mailing list will send scenarios (use cases) for midcom to the authors of the framework document, who will incorporate appropriate scenarios into their document. Christian Huitema has volunteered to compose scenarios for the document.
No resolution was reached on the inconsistent usage of definitions between the drafts; working members should propose specific text for the definition to the mailing list, which will need to resolve the inconsistencies.
An interim meeting has been proposed in conjunction with the SIP summit in Richardson, TX. The SIP meeting is May 1 & May 2nd, 2001. The chair and ADs will discuss the scheduling of an interim meeting. The interim meeting will be focused on eliminating any remaining confusion on models, and attendees will be expected to volunteer to produce text for working group documents based on the results.
The Chair reminded the working group that early review and objection was critical to meeting the time lines of the working group and urged working group members to make objections known as early as possible.
Meeting Recap:
The Chair began the meeting by saying that most important aim for the morning was to work through the drafts and eliminate any conflicts between them. She then began reviewing the status of the drafts. The deadline for both in the current milestones is August 2001, but the Chair hopes quicker progress can be made within the working group, in order to incorporate potential delay time at the IESG review stage.
The Chair then stated that the group needs to resolve some definitions, both for the clarity of its own discussions and in order to assist the IETF as a whole. Among the terms which need clear definitions are: middlebox, proxy, Application Layer Gateway, and the various participants in a Midcom protocol exchange.
Pyda Srisuresh then presented the framework draft.
The main goal for the draft is to create an architecture for middleboxes needing to externalize application intelligence. That framework should guide the development of the midcom protocol, with especial guidance for the security necessary when connecting midcom agents to middlebox. The architecture is restricted to firewalls and NATs, in accordance with the group's charter, and it does not discuss discovery.
The architecture presumes that there is a single midcom protocol interface, no matter what middlebox function or functions are in the midbox (i.e., the same interface for firewalls and nats). The current draft creates a taxonomy, however, for the midcom agents, dividing in-path midcom agents and out-of path midcom agents. A great deal of discussion from the floor challenged the distinction as written. Christian Huitema asked that "enterprise boundary" be eliminated from the description, as the use of "enterprise" might carry the wrong implication to some readers; he suggested "domain" as a possible replacement. It was suggested that a reference to Brian Carpenters Middlebox taxonomy document would be useful in clarifying the difference between in path and out-of path systems. Others felt that the basic distinction was flawed, as the functions were the same whether there were multiple boxes implementing those functions or note. The draft author asked for further review of the draft and asked for proposed language from those raising objections. The chair indicated that further examples would be useful, especially for out-of-path middlebox agents as the only example available appeared to be the decomposed NAT, where the ALG functions are diverted to external software processing boxes.
A question on the floor asked for clarification between the middleboxes treated in this draft and those examined in OPES; the Chair responded that this is the transport layer, where OPES is application layer. Michael Condry suggested that further language in the draft to clarify which middle boxes are at issue would be useful. The author agreed to add such language.
Christian Huitema pointed out that SIP proxies are in path for SIP messages, but out of path for media stream; he said that this seems to create confusion in the application of the in-path midcom agents. Author agreed to clarify that the signaling message path is meant in the existing distinction.
Christian asked whether outsourced agents for some of these middleboxes would affect the architecture. In particular, he noted you lose implicit knowledge of the path if you have something like a sip proxy which may need to talk to firewalls in multiple exit points. Chair noted that the discovery of which firewall is salient is out of scope. Christian agreed that this was fine, but that there was a design implication that the signaling cannot assume anything about whether its messages will take the same path as the packet flows. Author agreed that this was a design implication..
After further discussion of the distinctions among packet flows, the AD asked to remember that we were not here to define the characteristics of a middle box, but to design a communication system to cope with them. Elements of the middlebox operation (like packet diversion) are out of scope except as related to midcom protocol signaling.
Christian then indicated his belief that the confusion around some of these issues derived from the draft's never making clear the fundamental requirement of midcom, that we need a mechanism for allowing a client to open a tcp_listen in the presence of a NAT or a firewall.
The group then moved on to a discussion of the requirements draft, presented by Richard Swale. He first noted that the document as developed in parallel with the framework, so there have been some cases in which the two have diverged in terminology and architecture.
Discussion of the draft began with questions around the use of specific terms, such as "application client" and "application server", but moved quickly to a question of whether the draft serves the purpose of a requirements document at all. In particular, it was agreed that the document needs a set of scenarios or uses cases. The AD (Scott Bradner) noted that the draft contains descriptions of the middlebox functions which are valuable, but not appropriate for this draft. He asked that this draft focus more specifically on communication *to* the middlebox rather than the function within it.
It was proposed that the current requirements draft be abandoned and the requirements should be redrafted with the caveat that the requirements draft should use only terms that are in the framework document, with a strong focus on service scenarios. The focus on scenarios was strongly supported, but it was not clear that the draft needed to be scrapped.
After a suggestion from the floor that work on the requirements be suspended until the framework is completed, it was agreed that the working needed to work on both in parallel to achieve its milestones. The Chair asked both sets of document authors to eliminate text in their drafts that describes middlebox functioning unless that function is explicitly related to the processing of midcom messages.
The Chair then asked that as part of their re-write, both sets of document author expand their security sections and examine the current text, as she believes it not correct.
Eliot then asserted that flow direction is creating a problem in our understanding of these. He put forward an example derived from peer to peer communication (Gnutella). Some device with a fully public IP address A, initiates a communication with a device B, which is behind a firewall. How does device B get a publically addressable IP/PORT in order to be addressed by A? Scott Bradner asserted that a FQDN from a two faced DNS is the external binding, so that the original message goes to the client's inside address, at which point it requests an outside address.
After a complain from the floor that none of the scenarios were written down in the drafts. Christian volunteered to writes scenarios. He then went back to Eliot's case, noting the case of a home network where an external port is mapped to an internal service; he wants a common way to do that mapping as it is currently being done in a proprietary way, using a very weak security model (inside/outside). He believes we need scenarios and an inventory of existing mechanisms (in use in home gateways, socks, etc.). Chair rules the second out of scope. Agreement among volunteer, chair, and AD on scenarios as use cases for the protocol, not of the middleboxes.
Question from the floor about binding to ports; answer was that since it is not related to midcom function, it is a not issue. In a discussion about whether "inbound and outbound" do not have to be separate, the Chair noted that you might have a midcom policy on a per interface basis. After a further discussion of how complex the interface mappings might be, the Chair indicated that in this problem domain (firewalls and nats), that the inside/outside dual interface is a reasonable description. You might not want to see it not in interface terms, but in terms of source and destination address. Andrew noted that this might not be sufficient if the charter is to deal with what is actually out there, because there are firewalls that have multiple interfaces and there are NATs that care deeply about who session direction as well as interface direction.
The Chair then concluded the meeting by reviewing the action items, noted above.
Middlebox Communication Architecture & framework
MIDCOM Requirements draft