Last Modified: 2003-02-03
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].
| 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 |
| RFC | Status | Title |
|---|---|---|
| RFC3304 | I | Middlebox Communications (MIDCOM) Protocol Requirements |
| RFC3303 | I | Middlebox Communication Architecture and framework |
IETF 56 MIDCOM minutes, reported by Tom Taylor <taylor@nortelnetworks.com>. 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 requirements. 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 draft-ietf-midcom-semantics-01.txt ====================================== 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 needed. 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 pinhole? 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 allowed. 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. |