The MIDCOM (Middlebox Communications) Working Group met Thursday, March 21 at 1530-1730. Melinda Shore 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 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 is doing work on the semantic model. Jonathan Rosenberg 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 , Mahadev Somasundaram , Sanjoy Sen , and Steve Davies (being replaced by Pete Cordell ). 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 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 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 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?