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.
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 | |
| Apr 02 | Submission of STUN document for standards-track publication | |
| May 02 | Submission of pre-midcom document describing protocol for NAT traversal using relay for standards-track publication | |
| Aug 02 | Submission of document evaluating existing IETF protocols against midcom framework and requirements for an Informational RFC. | |
| Dec 02 | Submission of midcom protocol for standards-track publication |
Current Meeting Report
The MIDCOM (Middlebox Communications) Working Group met Thursday, March 21 at 1530-1730. Melinda Shore <mshore@cisco.com> chaired the meeting. Notes by Tom Taylor (taylor@nortelnetworks.com)
Agenda Bashing
==============
The agenda was accepted as proposed.
Status
=========
The MIDCOM Framework and Requirements documents have both been approved for publication.
The new charter has been approved and posted.
STUN is due April 2002.
Our unnamed pre-MIDCOM deliverable is due in May.
Process Going Forward
=====================
Mary Barnes <mbarnes@nortelnetworks.com> is to be the editor for the protocol evaluation document.
The Working Group is doing the semantic work in parallel.
-- process to be announced next week (last week of March)
-- Tom Taylor <taylor@nortelnetworks.com> is doing work on the semantic model.
Jonathan Rosenberg <jdrosen@dynamicsoft.com> commented that he was not sure if the work should go in parallel, given that the semantic description can be disposed of quickly. Melinda responded that the protocol evaluation will be messy and political, hence is best started as soon as possible.
Mary Barnes presented charts describing the process going forward.
Chart 1: Methodology Overview - Part 1
--------------------------------------
- Process open to entire WG.
- Contributors need to specify their intention to contribute an objective evaluation of a specific protocol (by April 3rd).
-- If there are multiple volunteers for the same protocol, priority is given to whomever puts in the first claim with a suggestion that the interested parties work together.
-- Objective is to NOT have multiple individual contributions for the same protocol.
- Specific protocol evaluation to be completed by April 19th.
- Open WG feedback on the specific proposals on the mailing list, allowing authors to incorporate WG feedback into their contribution to improve its positioning and completeness (April 19th- May 3rd).
- Final version of specific protocol evaluations due on May 10th.
- Final versions of specific protocol evaluationss due May 10
-- template will be provided
Some discussion of IPR followed the presentation. IPR claims must be revealed by April 3 to help people decide which protocols they want to work with.
Chart 2: Methodology Overview - Part 2
--------------------------------------
- MIDCOM WG protocol evaluation document to be comprised from the information from the specific protocol drafts (May 10th-May 24th)
-- Information is synthesized by the editor into a consistent format, with an objective comparison of the various proposals based upon the drafts (thus the responsibility is on the draft writers to ensure they completely evaluate their protocol against the requirements and framework and incorporate constructive input from mailing list).
-- first version of protocol evaluation draft available on May 24th.
- Open WG feedback on the draft (May 24th - June 7th) :
-- Discussion of amalgamated pros/cons of the various proposals
-- Any other issues with the draft.
- Second version of draft available on June 14th:
-- One Week mailing list discussion.
-- Updated draft posted for WGLC: June 28th
-- WGLC: June 28th-July 19th.
-- Time allowed for a second iteration of WGLC
Chart 3: Basis for evaluation
-----------------------------
- Fundamental basis for evaluation is:
-- MIDCOM Requirements: draft-ietf-midcom-requirements-05.txt
-- MIDCOM Framework: draft-ietf-midcom-framework-07.txt
- Format for individual protocol evaluations is not prescriptive but for an objective analysis should include the following sections/content:
-- Applicability to the MIDCOM Framework.
-- Identification of the MIDCOM Requirements that are satisfied
-- Identification of the MIDCOM Requirements that are "partially" satisfied
-- Identification of the MIDCOM Requirements that are NOT satisfied
- Template for WG protocol evaluation draft will be made available early in the process to provide some guidance and to solicit WG feedback.
Discussion of this chart revealed a concern to have detailed criteria beyond those shown. The WG will generate these more detailed requirements over next couple of weeks on the list.
Jiri expressed concern that adapting an existing IETF protocol will result in an unnecessarily complex midcom protocol.
Mary's next few charts summarized the timeline for the process, based on the dates given in the preceding charts.
Her final chart was as follows:
Chart 8: Other Considerations
- Conference calls can be scheduled to discuss issues that have not been resolved on the list or have deadlocked, but the goal is to work primarily via email.
- Specific dates are subject to change, however, to meet the August deadline, we need to stick with these at a high level. Any changes to these proposed dates will be posted to the list.
- IF progress isn't being achieved with the open nature of the proposed process, a design team MAY be formed to get the work back on track to meet the August delivery to IESG per the WG charter.
Melinda called for feedback on the process and on the criteria.
Pre-MIDCOM Design Team
======================
Melinda named the members: Jonathan Rosenberg, Ram Dantu
<ramd@netrake.com>, Mahadev Somasundaram
<mahadev@cisco.com>, Sanjoy Sen <sanjoy@nortelnetworks.com>,
and Steve Davies <sdavies@ridgewaysystems.com> (being replaced by Pete Cordell <pete@tech-know-ware.com>).
STUN Open Issues (Jonathan Rosenberg)
=====================================
Changes in -00:
- Answered UNSAF considerations - still awaiting response from IAB
- Alignment of parameters on word boundaries
-- not compatible with original draft
- Added missing parameter code
- Clarified meaning of changed-address
- Added security
Security issue: theft attack
----------------------------
- attacker snoops request
- injects fake response
- MAPPED-ADDRESS points to attacker
- client thinks this is its own address, hands it out
- media signalling applications go to attacker
Bad because it gives the attacker access to a variety of applications.
Rohan Mahy <rohan@cisco.com> noted limitations to the attack. If the NAT is not full cone, the attacker has to fake its source IP address to be that of STUN server. Attacker has to be on the path or local to the client.
Solution Requirements
---------------------
Server authenticates itself to the client
- same domain as the in which the client launched the request.
Client can validate the integrity of the entire response.
Server to client authentication typically based on PK
- web model
- want to work with servers you don't share a secret with.
Christian Huitema <huitema@windows.microsoft.com> warned that there are NATs that will remap what they perceive to be IP addresses in the content. Hence applications have to obfuscate vulnerable portions of the content.
-- take off-line.
Solution approach:
-----------------
Cryptographic Message Syntax (CMS) RFC 2630
- heart of S/MIME
- syntax for signatures, certificates, etc.
Problem: don't want to sign responses for just any request
-- would set up a potential distributed denial of service attack.
Hence the proposed procedure has a two-stage handshake, with a cookie in the initial response.
Issue: CMS implementation is probably 10-20 times bigger than STUN itself - other approaches?
Christian Huitema suggested that we may not need security for every mapping. If the first response looks OK, it should be optional to require the full signature.
Note to authors: add the is remark to the document.
Cullen Jennings <fluffy@cisco.com> asked why the exchange could not use a shared secret. Jonathan responded: this would be a brake on deployment. A single STUN server may have many clients. Cullen asked why the SMTP model would not work. Melinda answered this: the trust model different -- it is necessary to narrow access to prevent spoofing. Kerberos may be applicable in a year. Cullen remarked that SIP phones don't do that. Jonathan explained further that he wanted to preserve the nature of the server as a stand-alone resource. The code readily available. Cullen indicated that code size is his precise concern. The mitigating circumstance is that TLS and MIME share technology.
Ruling from the Chair: put it in the document, since the latter is a team output rather than a WG output.
Jonathan continued his review of STUN status in general. Beyond what had already been described, there is little else to do. Lots of implementations are underway, and products will soon be available. draft-ietf-midcom-stun-00 will be revised and reissued after the blackout. Then it will be ready for Working Group Last Call.
Comment: we could make the operation of the protocol more efficient by not having a timeout in the NAT so probes are not needed. Suggestion: put time value in the STUN packet from the server. Jonathan pointed out that if we want to have STUN directly manipulate NAT state we should do a proper protocol design for in-band control of NAT. Melinda said it was in her draft last year. She will reissue that draft, ask for BOF in Yokohama (but this is a separate problem).
Pre-MIDCOM Update (Steve Davies)
=================
'Thing'
Now a chartered item
Design team set up to propose a solution to the Working Group.
- Draft submission date May 2.
Allow inbound connections through midcom-unaware symmetric NATs using communications with server elements on the public side.
Mechanism: enable a client to obtain an address at a public relay.
TCP is in scope.
Issues:
- avoid implicit subversion of security policy e.g. running unauthorized servers
- out-of-band vs. in-band control of relay
- are symmetric paths required?
Slides
STUN Open Issues
MIDCOM Protocol Evaluation Process and Plans